Re: GNUe in actual production use?

Reinhard,

>>>>> "Reinhard" == Reinhard Mueller <[email protected]> writes:
 > Date: Mon, 09 Oct 2006 12:04:52 +0200

 > Joost,

 > thank you very much for your input!

 > Am Montag, den 09.10.2006, 11:24 +0200 schrieb Joost Helberg:
 >> Most people start typing and press `search' for searching. The fact
 >> that GNUe expects the user to first think (hit search button) and then
 >> put the search string in is counter intuitive.

 > It might turn out tricky to find a "one fits all" solution here - others
 > have experienced that users start typing and then press "save" because
 > they just want to enter a new record.

 > Would you think that a parameter whether a form should start up in query
 > or in insert mode would help with this?

I don't think the concept of a `mode' is the best thing to do.
Entering data and only then deciding what to do is pretty standard for
most people.

 >> This problems is made worse by an issue with the search-toggle button
 >> which is active sometimes without being in search-mode.

 > This has probably happened in cases when switching to search mode failed
 > - the button has remained pressed in then. This should be fixed for most
 > (if not all) cases with current releases of forms.

Good for GNUe, I'll try it.
What about dropping the `mode' altogether?

............

 >> I use some master-detail forms and there is no (to my limited
 >> knowledge) standard way to create rows referring to a newly created
 >> master-row automatically. This means that after creating a
 >> master-record, a query must be performed in order to get the
 >> detail-records point to the right master. After that, new
 >> detail-records can be added.
 >> Of course this can be solved with some kind of trigger, but this case
 >> is so general, it should be dealt with automatically.

 > This problem has been solved with gnue-common 0.6. GNUe-Forms now uses
 > the OID to requery the master immediately after it has been inserted.

Good to hear.

 >> GNUe doesn't handle default values of attributes which are handled by
 >> the database server.
 >> This means that only upon saving and re-querying a record, the default
 >> values appear. It is possible of course to automatically query default
 >> values and make them appear in the form.

 > Starting with gnue-forms 0.5.12, each record is requeried immediately
 > after the insert, so default values filled in by the database (and other
 > stuff happening in db triggers) gets visible after the insert.

But this means that the user doesn't see the database-defaults while
entering data, the user will only see these after inserting. That's a
bit late, as the user may have entered (superfluously) data where
defaults would have worked too (or even better).

 >> In my datamodel I use an attribute `id' as a general purpose
 >> reference. This means that all relations are in terms of an attribute
 >> containing the id of the row referring to.
 >> This id is automatically generated and not part of any user-editable
 >> form.
 >> Since one of the more recent versions of GNUe all my forms stopped
 >> working as the value of the id was used for re-querying the record. As
 >> the GNUe-forms known value of id is null, the re-query fails.
 >> I wonder why all attributes of a row are used for re-querying?
 >> Especially in case one or more keys are known, this is not
 >> necessary.

 > In gnue-forms >= 0.5.12, this should work exactly like you describe it
 > if you explicitly set the primarykey="..." attribute for the datasource.

Cool, I'll upgrade one of these days.

 >> In case of PostgreSQL every insert returns an oid for
 >> re-query use, I'm sure other servers do something similar.

 > Unfortunately no, not all servers. Actually, even PostgreSQL has stopped
 > to create OIDs in more recent versions, so we recently decided to not
 > use OIDs in the Postgres backend driver - most of the current installs
 > have OIDs switched off.

I'm sorry to hear this. First they removed the `heavy archiving'-mode
(which doesn't ever delete records and extends the table-name in
queries with a valid-in period), and now OID's!

 >> There were some other issues, I'll replay them as soon as I have some
 >> spare time.

 > Thank you very much!

 >> GNUe still is the best solution around, so I'm not really complaining :-)) 

 > You're not complaining, you're helping! :-)

I know, thanks for your extensive replies.

Joost

-- 
Joost Helberg
Snow B.V.        http://snow.nl Tel 0418-653333 Fax 0418-653666