Re: [GNUe] [Bug] gnue-forms / gnue-appserver: OnChange / abort / editable="new"

[David Ayers]

Hello Reinhard!

Reinhard Mueller schrieb:
> Am Samstag, den 03.05.2008, 11:48 +0200 schrieb David Ayers:
>> When saving an newly to be inserted object fails due to an abort
>> during the OnChange processing in the gnue-appserver, the form's field
>> property editable="new" is misinterpreted in the sense that the
>> fields become deactivated even though, as the status line also
>> indicates with "INS", the object is still new.
> 
> there are a few things to note.
> 
> First of all, the "INS" in the status line refers to Insert mode as
> opposed to Overwrite (typical behaviour of the "Ins" key on the
> keyboard). The record status is indicated by the *other* 3-letter code
> in the status line, like "OK" or "MOD" (for "Modified").

Ah thanks!

> Second, I could not reproduce the behaviour with OnChange but only with
> OnValidate. Could you please double-check?

Ahm... yes I haven't implemented OnValidate, but actually the check I'm
making /should/ be implemented in OnValidate... especially if I call
abort.  So unless you want me to debug thism I would 'correct' my code
and go from there.

> Third, the behaviour is *somewhat* correct for OnValidate: Since
> OnValidate only runs on commit, the data is already written to Appserver
> and the object *does* exist, but the transaction is not yet committed.
> The object is very much in a status like a record in a SQL database is
> between the INSERT and the COMMIT statements.
> 
> We might have to think a lot more about exception handling and handling
> of started but unfinished transactions, but at least I wouldn't consider
> this a clear but which can be fixed without some deeper thought about
> the basic concepts.

Well let's look at this... the reason to implement OnValidate is to
insure the data is, well, valid and consistent.  The purpose is to raise
an exception when the data is invalid.

>From the documentation:
`OnValidate' can prevent the commit to happen if it raises an
exception with `abort' or by other means.

[Now I'm not sure what the 'other means' refers to wrt the prevention
but let's ignore that for now.]

In my case it validates that a property contains valid input before it
is stored and subsequently changed to a non-editable read-only property.

So the expectation of a naive application developer like me would be
that if validation fails as documented (ie an abort), the entire
transaction from the view of the appserver should be rolled back as if
it never happened and the client that requested the commit is notified.

The client should keep it's state as just before the commit was
requested.  Which is why I believe the commit method should return
return True/False to let the application act accordingly.

A have worked with a few persistence frameworks and from my experience,
contrary to the current gnue-appserver documentation, I think it should
be considered an error to allow changes during validation.  Instead an
extra pass (let's call it OnChange ;-) ) should allow all changes and
propagation there of... in memory before validation.  The subsequent
OnValidate should only be allowed to verify that things are consistent
before the state gets stored.  If the validation fails, all changes
should be discarded.

At least that's what my ideal persistence framework would do ;-)

Cheers,
David