cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
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 22:51:05 GMT

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

> Sylvain

thx and regards,
Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message