The question here is, do you want to do a page reload, or do you
want to to an asynchronous update using Javascript ?
That doesn't matter, it should both be possible, and any future
different behavior wrt the request / response cycle.
Anyways, when we are talking about Rife, isn't it more useful to
talk about what is supported in Javascript and DOM events, rather
than what is supported in Swing ?
No, since DOM Javascript events are an implementation detail. I was
just giving Swing as an example since Wicket uses it as an example
and it seems to work well for them (and its popularity). It doesn't
mean though that it should be done like this, it's just one way of
creating an event system for widgets that is based on listeners,
delegation and bubbling.
W.r.t. browser widgets, I guess it would be nice if I could (say)
map my Element to a Tree widget, and I could optionally declare an
Element method like "onExpand" which would auto-link to a Javascript
onExpand() handler in the browser that could handle data from the
servlet. But that sounds like a Javascript hell, unless there is
some Ajax framework that can do the grunt work.
Imho, the widget element should be responsible for rendering that
tree widget, which means that it can (and will) map events to
whatever server-side solution we come up with. So if it's an Ajax
widget, this will perform an XmlHttpRequest to fetch the updated
model and any javascript that needs to be executed. If it's a regular
XHTML widget, it'll re-execute the element as an embedded (widget)
element, call the event (which seems to me to map to a submission)
and let the embedded element re-render itself and the parent page in
the new state.
BTW here's an article that describes what a conceptual nightmare
a lot of Ajax-type stuff is, and how declarative programming is
our best hope of rescue:
http://www.xml.com/pub/a/2005/06/29/deviant.html
Sure, Ajax without a (declarative) framework is madness.
These widgets can then themselves support new event
types that are specific for them. This is the model that Wicket uses.
I'm not sure it makes total sense in the context of RIFE and if the
same design should be applied, which is why I'm soliciting input.
If my browser tree widget maps to my Element, then maybe
I _could_ extend its behavior, if there is also a way to
provide the corresponding Javascript for the browser.
That should be part of the render phase, which can optionally provide
the javascript to the browser.
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
