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 on-change?
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?)
<snip/>
regards,
-marc=
PS: don't let above sound like defensive, I'm wide open to changing and fixing this
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
