gnue
[Top][All Lists]
Advanced

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

Re: [GNUe] [Bug] gnue-forms / gnue-appserver: OnChange / abort / editabl


From: David Ayers
Subject: Re: [GNUe] [Bug] gnue-forms / gnue-appserver: OnChange / abort / editable="new"
Date: Tue, 06 May 2008 11:42:06 +0200
User-agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420)

Hello Reinhard,

Thank you for the explanation!  I'll reply the easy part first while I
digest the rest :-)

Reinhard Mueller schrieb:

> Am Montag, den 05.05.2008, 19:29 +0200 schrieb David Ayers:
>> 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 subsequentOnValidate should only be allowed to verify
>> that things are consistent before the state gets stored.
> 
> In fact, the possibility to allow changes in OnValidate has made us
> quite a headache, especially in making sure that changes that happen in
> OnValidate are then subsequently also validated properly.
> 
> How do other frameworks handle changes that happen in OnChange? Do these
> changes also trigger OnChange again, recursively? How do they avoid
> endless recursion loops?

Some of them process the trigger only once and any subsequent changes
are made without further triggers.

Or they simply cause recursions and delegate the responsibility to the
application to break them.

My personal preference is the latter but I would try to supply the
application with some meaningful context to help it decide on when and
how to break a recursion.  (Something like a transaction id, and the
original changed attributes before the initial OnChange was triggered).

Mostly this happens in only a few, but sometimes 'key', places.  'Key'
as in the sense "this is the special feature for which the customer is
willing to pay for these modifications".  So I believe it would be
suboptimal if the recursion were avoided.

Cheers,
David




reply via email to

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