Tim Larson wrote:
>On Thu, Sep 09, 2004 at 03:46:52PM +0200, Sylvain Wallez wrote:
><snip/>
>
>
>>I started implementing an "on-create" event listener, but failed on that
>>same problem, as the whole form must be in a consistent state before
>>that event can be fired, because the event listener can potentially
>>reference any other widget.
>>
>>
>
>What were you going to use "on-create" events for? I am guessing mainly
>for new repeater rows and newly referenced union cases?
>
>
Exactly. In flat forms, custom initializations can be done in the
flowscript between "new Form()" and "form.showForm()", but I the case of
dynamically created widgets, this cannot be done that way.
I have some complex use cases where the case field of an union, itself
in a class, has a selection-list that is defined by analyzing the values
defined somewhere else in the form.
Still following me? If not, you need to attend my presentation at the GT ;-)
So the idea is that in "on-create", the widget gathers in the form the
necessary data to build and set its own selection list.
Even for flat forms, this create-event can allow custom initialization
code that currently is written in the flowscript back in the definition,
thus making the form definition self-contained in a single file.
>>So your initialize() stuff could be a solution to finish the
>>implementation of create-event. However, that event must also be fired
>>when a widget is creater later during the life for the form, e.g. when a
>>new repeater row is created. So initialize() must also be called in that
>>case.
>>
>>
>
>I already handle that case, and also calling initialize() for the
>created-on-demand child widgets of union widgets. Should I commit?
>
>
+1. I'll add the "on-create" stuff on top of this.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
|