cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
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 11:04:02 GMT
Marc Portier dijo:
>
>
> 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 Form.save() 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?

All the 4 apply. The idea of the CForm (instance) lifecycle is similar as
avalon components lifecycle:

http://avalon.apache.org/framework/principals/lifecycle.html

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

Why? I think we can "check" if there is a binding for this form. The idea
behind all the thread is because the binding must be part of the overall
form management. If CForms are related to form handling the binding must
the the interface between other components and the CForms itself.

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

Yep. The problem is this right now. Also as I pointed before, there is a
need to set some defaults values and a need to make some chanes just after
load data (using binding) and before the form is displayed.

As an example, see the car selection demo. The demo works fine when we
need to create a new entry, but currently there is a problem if we have
already loaded data and call the car form. The already loaded data will
not be displayed correctly.

Also, I see a better idea to create a similar handler as the one we used
to manage custom validations:

form.validator = theCustomValidatorFunction;

function theCustomValidatorFunction() {
   return true;
}

That way we can easily manage the after load stuff.

WDYT?


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

AFAIK in other forms frameworks the changes made by code (internal
changes) don't emit new events. Only users changes emit new events. I
think this is correct since we are making internal changes then why we
need to know again we are making changes.

If we will emit new events, then there is (theoretical) posible to write a
endless loop just changing other widgets values that inevitable will emit
another event.

Also emiting new events by code changes just create more overhead, since
programmer already know what he is doing.

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

I see the need to fill default values + a need to make some last changes
just before displaying the form. This to actions need to be done in
diferent time. The default values can be load in the initialization phase
(1) then just before displaying the form we need another chance to make
changes. This is a normal approach.

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

??? I don't see it as a good idea. We cannot take as a fact that the user
will interact with the form always. There can be cases where the user can
show the for and close the browser forever. So in this case I prefer to
release the components just before show the form. This was discused
before.

>> How does all this sound?

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

No hay problema ;-)

Best Regards,

Antonio Gallardo

Mime
View raw message