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 }
