cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [CForms] Form lifecycle and events
Date Tue, 30 Dec 2003 09:29:23 GMT

Antonio Gallardo wrote:

<snip />

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

again (see other post), save() in my view can be called multiple times 
to save one form back to multiple back-end-objects, you would have a 
hard time knowing if this was the last save() without the additional 
destruction phase, no?

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

I don't see it yet: I would assume that the same logic applies for 

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

but this suggests that there is a before-change maybe?

to me on-change sounds quite ok, there could not be a detection of 
change if somebody didn't change a field and submit it, right?

only subtle extra meaning is maybe that on-change sounds like there is a 
way to veto the change?
(maybe on-changed offers the compromise?)

also, I still don't see a reason for different <after-load> (probably 
due to me not understanding your above example)

in any case, if the use case is there I'ld like to suggest this 
alternative.  IMHO in most cases the same logic needs to be triggered 
when values change, regardless of their life-cycle phase... so if there 
is phase-specific logic to execute then it maybe makes more sense to 
allow the event itself to carry that information: getLifeCyclePhase() 
(rather then having different events?)


PS: don't let above sound like defensive, I'm wide open to changing and 
fixing this
Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message