Sylvain Wallez wrote:
Hi all,
A short post to say that I've been working intensively on event handling on Woody since yesterday. I'm nearly finished with it, and obtained something powerful-yet-simple, that allows to define event handlers on actions (ActionEvent) and fields (ValueChangeEvent). The goal is also to
yoohoo!, looking forward.
in fact I thought about this from the start, but failed to explain to myself how it should look like (I also kept on mixing it up with client-side javascript)
Well, if you fail to explain to yourself, I understand why we sometimes don't understand your posts ;-D
care to textualize some preview on what goes about before we see the code?
Yep. Here it is.
At first, I wanted to add event listeners to widgets (i.e. the _instances_), but that did not work, primarily because a repeater dynamically creates widget instances and secondly because it requires listeners to be painfully defined programmatically each time a form is instanciated (in an action or flowscript).
So event listeners are defined in the form definition. I currently have defined a ValueChangedEvent for data-aware widgets (field, booleanfield, aggregatefield) and ActionEvent for actions. We also need a RepeaterEvent.
Two implementations of EventListenerBuilder exist : one that creates a Java class (classical EventListener) and one that wraps a JavaScript snippet. Just as in DHTML, that snippet has some predefined variable : this (the widget) and event. If called within a flowscript, it also has access to the precious "cocoon" object. I still have to see how to create a "cocoon" object if used out of the flowscript context.
The definition therefore looks like this :
<wd:field id="foo">
...
<wd:on-change>
<wd:java class="com.my.Listener"/>
<wd:javascript>
var list = this.parent.getWidget("thelist");
list.selectionList = Packages.com.my.App.getSelectionForTheList(this.value);
</wd:javascript>
</wd:on-change>
</wd:field>
Similarily, there's an <on-activate> on <action> widgets.
I reused the JSF patterns for event handling : events are buffered until the current processing phase is finished and fired afterwards, to ensure the widget tree is in a consistent state.
I still have to define also the ability for the form to be submitted when a widget's value changes. Considering the car selector example, this would allow to refresh the model list as soon as the maker is changed withouth having to push the "select maker" button.
I'm thinking of adding a new "submit-on-change" attribute on <wi:styling>, but I'm wondering if this belongs to the view or to the form definition. Seems better on the view.
also this links back to another wild idea I'm having
I'm still not quite satisfied with the way the repeater-binding (the not simple one) needs to operate for detecting new/deleted/syill-existing rows in the repeater...
So I hope the way you handle valuechanged can give some inspiration on how to mark the changed state of repeater rows?
Aha ! I was also thinking of an event-driven binding, but kept this wild idea for now : the binding would register itself on the repeater and "collect" modifications.
BTW: I assume that the ValueChangedEvent is holding both the old and new value?
Of course !
allow event listeners to be written both in Java (classic-style) and in JavaScript (flowscript-style).
Makes sense.
I guess reusing the awt eventhandling interfaces is out of the question?
Using AWTEvent doesn't really makes sense, but the new FormEvent class extends java.util.EventObject, and the listeners extend java.util.EventListener. However, I used the convenient AWTEventMulticaster as the base class for a FormEventMulticaster.
Not that I would consider it as a breaking design point to start using it, but yesterday someone showed me usage of jbeaver (see at http://www.ratundtat.com/index01.htm?menue=40, it's not oss but it didn't look entirely impossible to create something similar.) and I couldn't help dreaming about a common GUI description language that could result into both Swing and Woody based apps...
And SWT... Some of my current wild thoughts is to use Woody and flowscript to build Eclipse plugins. Imagine every component coming with its own Woody form and associated flowscript and binding : building a Cocoon IDE for Eclipse can become quite easy.
From that angle: being able to share your event-controllers might make sense (although wrapping them inside specific listener interfaces should not be that hard)
Sorry, don't understand: what are "event-controllers" ?
This morning, I was reading an article about JavaServerFaces (never did look at it before), digged a bit, and discovered that what I was doing was very close to JSF event handling, and grabbed some interesting points. Digged further, and found the lifecycle thing very interesting, and once again close to the way Woody handles form processing. Parts of the JSF are not so bad and can be a good inspiration source ;-)
I remember that Bruno had a look into the specs (and of the XForms) when in the pre-woody phase (when the codename was still yaff) of trying to nail down some initial design and try outs
that together with the fact that we try to solve the same issues porbably accounts for some 'similarities'
Exactly. I also did read the XForms spec before comparing Woody and XMLForm back in August, and JSF, although complex and mixing concerns in the JSP, contains some interesting points in event handling and form processing lifecycle.
I heard some good things about ASP.NET as well, and I remember Carsten's Dywel effort is inspired by his experience with webobjects: there really is more inspiration out ther and I'm hoping some of this inspiration will come together on the Hackathon-day http://wiki.cocoondev.org/Wiki.jsp?page=GT2003Hackathon
(suggestion: you (and Bruno) should ad yourself as an intro-speaker on the topic, no?)
Sure ! This topic should allow leave much room for participants to bring their respective experiences on the table. Examinging them to merge the good things into Woody is IMO a good way to have a strong form framework that satisfies everybody.
Once this infrastructure is in place, I plan to write specialized repeater-actions that automatically handle add/delete row in repeaters.
More soon...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
