cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Broke car selector sample [Fwd: cvs commit: cocoon-2.1/src/blocks/woody/samples/forms car-db.xml]
Date Mon, 29 Dec 2003 23:00:28 GMT
Marc Portier wrote:

>
>
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Hi all,
>>>
>>> I broke car selector sample :-)
>>>
>>> Problem is that when you assign / bind initial values to the form, 
>>> <on-value-change/> events are not fired, and form ends up in the 
>>> inconsistent state. Quick hack I used to fix this was to make 
>>> Form.fireWidgetEvents method public and call it directly from the 
>>> flow/action to make sure that all is ok; but this is clearly a hack 
>>> and I'd like to hear "expert opinion" on the subject.
>>
>>
>> The solution is to tie the loading phase to the global form 
>> processing. I started this by adding load() and save() to the Form 
>> class, but left them commented out waiting for some more thoughts in 
>> this area, since the binding is strongly separated from the Form object.
>>
>> Now your use case clearly shows that making the binding an integral 
>> part of the form processing is useful.
>>
>> So let's officially introduce Form.load() and Form.save() and make 
>> them the preferred way to use the binding framework.
>>
>
> Sylvain, care to explain a bit more?
>
> I do remember a more conceptual agreement on binding being a natural 
> part of the form's being (although the original late arrival of 
> binding in woody kept it modestly separate) and I thought we said back 
> then that save and load on a form were logical extensions...
>
> So I'm quite +1, I'm just not fully aware of what it is about yet...


It's just about that: integrate load an save as integral parts of the 
form processing lifecycle.

The processing phases are then the following:
1 - initialization
2 - load
3 - read from request
4 - validate
5 - save

Phase 1 can be useful if some widgets have an initial value and some 
others have dependent values. This allows event listeners to be 
triggered in the initial phase.

Phase 2 is optional and should normally occur only once.

Phase 3 can occur several times (the form can be redisplayed many times)

Phase 4 can occur several times also, but not necessarily after each 
phase 3 (e.g. repeater actions don't validate the form)

Phase 5 is optional and should normally occur only once can only happen 
if phase 4 is successful

Maybe we also need a phase 6 for destruction ?

How does all this sound?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message