[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUe] GNUe in actual production use?
Re: [GNUe] GNUe in actual production use?
Mon, 09 Oct 2006 13:18:59 +0200 (CEST)
>>>>> "Reinhard" == Reinhard Mueller <address@hidden> writes:
> Date: Mon, 09 Oct 2006 12:04:52 +0200
> 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
>> 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
>> 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
> 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.
Snow B.V. http://snow.nl Tel 0418-653333 Fax 0418-653666
Re: [GNUe] GNUe in actual production use?, Joost Helberg, 2006/10/09
Re: [GNUe] GNUe in actual production use?, Wolfgang Keller, 2006/10/10