Reinhard Müller (reinhard) asked about focus triggers in GNUe Forms - it seems like navigating from one record to another (like scrolling to the next record) fires the FOCUS-OUT triggers for the block with the old record loaded - and the FOCUS-IN triggers for the block with the new record loaded. He understood the reasoning for having both focus-in and focus-out - you can do consistency checks in the focus-out trigger and the user can never navigate out of an "incomplete" block. James Thompson (jamest) confirmed this, and noted that each type of focus trigger could be set at form, block or field level depending on the type of validation required. Reinhard understood this, but was more interested in the case when you don't move the cursor at all - but you just navigate to the next record - i.e. you *stay* in the same field, entry, and block - but the current record of the block changes. James thought that this should still fire the focus triggers. Reinhard agreed, however I found it does *only* fire the block level triggers not the entry-level or page-level triggers.

James had not been aware that entry-level triggers and page-level triggers had been added - he was struggling to think of example off top of head where I'd need them vs a block or field level trigger. Reinhard wondered maybe they were done "just to play safe" when the distinction between a field and an entry was introduced. James agreed - it allowed developers, for instance, to have an entry-level trigger that would work on all instances of the same entry, even if they were in multiple fields on different pages of a multi-page form.

Reinhard said that he would change the code to check focus-in and focus-out type triggers at all appropriate levels whenever the focus changed. He queried the order that the various types of trigger should be checked - he felt that it should be pre-focusout - pre-focusin - change focus - post-focusout - post-focusin. James agreed.

Later, Reinhard noted that the order of triggers he had proposed turns out to be a lot trickier as it seems at first sight. The logic did not necessarily work, for instance, when inserting a new record. He could also foresee triggers conflicting with each other - for example if post-focusout says it's ok to lose focus but pre-focusin says "i don't want it". He wondered if it would be simpler to have fewer types of triggers - just a single on-focusout before creating or moving record, and on-focusin (which can not block) afterwards. Jason Cater (jcater) explained that the original rationale had been that pre-focusout could block - in fact, that would be its main purpose - but that then the others were called knowing that the focus was changing. In theory, any of the pre-focusout triggers at event, block or page level could refuse to allow the focus-out to happen (e.g. for data validation) - only if all the pre-focusout triggers at each level succeded were the post-focusout triggers at each level then checked. Reinhard noted that this meant running the post-focusout *before* the focus *really* leaves the entry/block doesn't hurt at all. Jason agreed - as we know that it will in fact leave the focus - only the pre-focusout triggers could actually block changing the focus.

Reinhard noted that this actually meant keeping to the current order of trigger types - 1. pre-focusout - 2. post-focusout - 3. actually move around - 4. pre-focusin - 5. post-focusin - where only 1. can block. But at least he now understood the rationale behind this.

Reinhard Müller (reinhard) noted that a lot of attributes of GFBlock and GFField are changeable in trigger namespace and wondered what was the reasoning behind this. Jason Cater (jcater) explained at one time, our specifications for forms was that triggers could practically build a form at runtime and anything/everything was changable/scriptable - that was probably a pipe dream (and probably not necessary) - but it's possible the code you saw was the start of that general trend. Reinhard noted that the dream of building a form at runtime, whilst theoretically possible in a two-tier environment (GNUe Forms client talks directly to a database), wasn't really practicable in a three-tier environment (GNUe Forms client talks to GNUe Application Server talks to database), as there would be no mechanism for triggers in the GNUe Forms client to dynamically create new objects on the GNUe Application Server. He noted that, as of time of writing, *all* possible attributes of the <block> tag were exported to trigger namespace - autoCommit, queryable, editable, deletable, autoCreate, autoCommit, autoNextRecord, transparent - similar for GFField - maxLength, minLenght, queryDefault, case, required... I think practically none of them are very useful, and with some of them you might even be able to screw something up if you change at runtime.

Alex Bodnaru (alexbodn) asked for help to activate the inventory demo: the data is ok in the gnue database but there is a query that complains there is no oid. Reinhard Müller (reinhard) was not sure the inventory demo is functional any more at all - I haven't tried it in literally years. James Thompson (jamest) explained that if a table doesn't define a primary key then our system falls back to using oid to uniquely identify rows (for example, in updates). However, the postgresql database software (which was the most common database software people tended to use with GNUe) had recently dropped the oid column by default in new tables. In any case, the preferred way of dealing with this was to tell the datasource (GNUe's connection to the database) what column - or group of columns - represented the primary key in the underlying table. GNUe would then use this to identify unique rows, rather than the object id. This would work regardless of whether the database software GNUe was being used with had object ids or not. Really, object ids were only needed when a table is defined without a PK - which is really a bad practice that i'm very guilty of. Reinhard confirmed that the GNUe datasource would use the primary keys on the table, but only if the datasource definition told it what the primary keys were. Alex confirmed this - it stopped complaining only after i have added the primarykey option.

Later, James noted we have a bigger issue than i thought - as I just created the zipcode table with a PK - and the datasource still attempts to use the oid column in the query. Reinhard said that the reason for this was because the primary key field can change on inserts if there is a trigger on db side - so the only really reliable record identifier is the oid. James replied that the oid isn't in newest postgresql. Alex said that it could still be switched on - you may create the table with oids option. Reinhard asked are oid's depreciated to use or are they just turned off by default but still a valid option? James grabbed the latest tarball and read the release notes, reporting that reading the release notes it looks like OIDs are going to be around for a while - just not created by default.

Reinhard Müller (reinhard) asked what is the easiest way to enforce uniqueness of a database column? (other than creating an unique index which will result in db exceptions to be thrown at the user) He did a PRE-FOCUSOUT trigger in which a query a second datasource pointing to the same table to find out whether the value already exists - but that doesn't seem too elegant and did not catch duplicates if you make both entries at the same commit. James Thompson (jamest) said my users get the dupe entry sql error. Reinhard replied ok, so you simply pass the SQL backend error to the user - same for enforcing referential integrity? (e.g. making sure no master is deleted as long as details exist). James said he had actually gone even further in using back-end (database) validation - something i've done in postgresql is setup on update triggers on my invoice table that block updates after the invoice has been faxed to customer. i'm thinking that the error message generated by that trigger is displayed nicely by forms - well, wx24, i've not looked at 2.6 yet. Reinhard said that wx 2.6 was slightly different - you get the exception text - with clicking "details" you get the SQL statement that caused the error (in case of an SQL error).

However, Reinhard was not that keen on passing backend error messages to the user - as they look too techy - and they are (what is a problem for me) in English generally. James wondered if we need a per form mapping of some sort - so you can define "If you get this error. Display this instead" Reinhard had thought about this, but that would mean to parse backend error messages - depending on what backend you use and probably even on the backend version - maybe also on the current locale the backend runs on. This would take away the possibility to migrate to a different backend easily.