[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUe] GNUe in actual production use?

From: Reinhard Mueller
Subject: Re: [GNUe] GNUe in actual production use?
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?

> 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.

> The comboboxes don't allow SQL wild-cards. The user in search-mode is
> then confronted with a Python stack-backtrace!

In the last release of forms, we have added the option to search for
empty fields in dropdowns. Search for SQL wildcards is currently not
possible in dropdowns, and I am not sure what would be the best way to
implement this (from an user perspective).

However, I certainly agree that there should be no traceback if a % is
entered. I immediately entered this in our bug tracking system and will
have a look at it.
(note: the traceback happens whenever an invalid value is entered in a
dropdown in search mode)

> 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.

> 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.

> 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.

> 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.

> 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! :-)

Reinhard Mueller
GNU Enterprise project (

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

reply via email to

[Prev in Thread] Current Thread [Next in Thread]