cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject [CForms] Form lifecycle and events (was: Re: Broke car selector sample)
Date Mon, 29 Dec 2003 23:59:46 GMT
Sylvain Wallez dijo:
> 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.
> 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

I was waiting for this thread! :-DDD

> Maybe we also need a phase 6 for destruction ?

I think it is not necesary at all. If someone need processing at this
time. We can easily manage any situation just before saving or after
destruction. Something between them is not necesary.

> How does all this sound?

Overall sounds great. The phase 1 can be used for default values and the
load() can rewrote the default values without checking.

I think we can also add a new tag <wd:default/> for <widgets/>.

I think we also need an event handler "after load" (after phase 3).
Sometimes we need to fix some values based on what we got from the DB. As
an example we can present a synchronized set of comboboxes where the value
selected on the 2nd combo dependens on value of the first. The 1st combo
act just as filter for the 2nd combo.

BTW, I don't like the term "on-change" because it is not clear when it
happens: after or before change. I will prefer names like:

<after-change>, <after-load> etc.

... While writing I think we can add to the form this type of events. I
know I am already outdated in this topic and you are a step further here.
Anyway I need and will to read in wiki the CForms events before extending
in this area. :-DDD

Best Regards

Antonio Gallardo

View raw message