cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [CForms] Form lifecycle and events
Date Tue, 30 Dec 2003 11:24:26 GMT
Marc Portier dijo:
> 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?

Nope. Because it is an instance issue. Every form will have his own space.
This is similar as the form.validator handler for validation. No matter
how many instances of the same form are currently running, the caller send
the form we need to validate. The same will apply here (even in the save

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

No always. Please review the car-selection sample. Also I see a "name"
problem if we are calling the on-change event at the startup. The is not a
true on-change event since the user not changed nothing. This is a on-load
event for the widget. Isn't it?

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

I think this would be another step. Sometimes the before change is needed.
Also in fat clients there are more events for every widget:

on-create, on-initializate, on-getfocus, on-lost-focus, on-destroy, etc

This event give more freedom to developers. Of course I am aware of the
problem in an HTML environment.

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

I have a problem trying to fill an edit form with 2 combos from a table
that has 2 fields as Primary keys. One of these keys is a Foreign key form
another table.

Maybe you are right that we can already use the on-change event to do
this, but the actual documentation have some gaps. :-(

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

Nope. I prefer to see widgets with his own lifecycle.

I think there is a mix of concepts because the <wd:form> and the
<wd:repeater> are widget when in fact they are widget containers. And this
is another level.

> PS: don't let above sound like defensive, I'm wide open to changing and
> fixing this.

I know. We need to discuss this more before making the final decision. It
is OK to me. I am glad to be part of this. :-D

Best Regards,

Antonio Gallardo

View raw message