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 Tue, 30 Dec 2003 09:13:06 GMT

Sylvain Wallez wrote:

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

still don't get the term 'integrate' in his technical meaning?

is the following list to be seen as:
1/ subsequent calls in form.showForm()
2/ or even inside Form.processRequest()
3/ or are they just typical
4/ (or required?) order of methods called from end-user code or script?

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

hm, there is now (maybe too much?) the flexibility that I can use 
multiple bindings to bind the same form to/from maybe multiple 
backend-model-objects (just to name a use case we would be killing)

afaiu the original statement in this thread is about missing events 
after a binding has loaded it's data?

also: even with binding in place there will be a need IMHO to have 
access to widgets itself and thus we are able to just setValue on those 
(regardless of any binding, or initialization 'phaze' timing! This is 
there and can thus happen any time, no? Event-handling should be 
triggered then too?)

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

yes, but I really see Phase 1,2,3 as alternatives for the same thing: 
setting values on widgets which possibly can lead to events fired?

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

for cleanup of temp resources assigned to the form probably?
(memories of the upload-widget stuff?)

> How does all this sound?

sorry to be so boneheaded, still trying to understand :-(

> Sylvain

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

View raw message