Hi list,
We're having trouble deciding how to best implement ajax. Actually, I
use the term ajax - just as the rest of the world currently - to denote
the roundtrips generated from javascript and partial page updates,
without that nescesarily being done with xml messaging (which is part of
the official ajax definition).
So far, we are thinking about the ability to register 'handlers' for
ajax requests with components. There is some code in CVS for this now,
which uses Dojo for generating the roundtrips. Using these handlers
looks like:
RequiredTextField integerTextField = new
RequiredTextField("integerProperty", Integer.class);
integerTextField.add(new
ValidationEventRequestHandler("onchange"));
The ValidationEventRequestHandler (at this moment I call all ajax
handlers 'EventRequestHandlers', but that could change) is attached on
the 'onchange' javascript event handler; when the textfield has changed
input and the user leaves the field, a roundtrip will be generated,
resulting in a call to the request handler (which in this case validates
the component). This all works. Now for the hard part.
Basically, I see two options:
1. Develop ajax handlers on a rather ad-hoc basis. You'd have to know
what other components can be 'touched' by an ajax call. The handler has
to figure out in what ways the page is affected, and is responsible for
generating and sending e.g. javascript that can be used to update the page.
2. Solve it fully generic. One idea of how this could be done:
i) Keep a copy of the page rendering (e.g. a StringBuffer) that just
rendered.
ii) Right after an invoke of an ajax handler, render the page again
to another buffer.
iii) Compare the last rendering with the one that was saved from
last time, and make some kind of a diff.
vi) Send the diff only, and have some javascript update the page
based on this diff.
The great advantage of the latter method, is that you can stay very
close to the original way of programming Wicket applications. For the
validation example of above, it would mean that you can just trigger the
validation itself, and any feebackpanel/border/attributemodifier that
changes because of the validation is automatically rendered without any
action required in the ajax handler. That would making ajax
functionalitiy a breeze.
The great disadvantage is ofcourse session size (we would need to keep
multiple rendered pages in our session) and the fact that it is more
expensive to render the whole page and calculate a diff, then it is to
just let the handler write out the javascript that is needed. One thing
we could do about the session size, is doing a render just before the
ajax handling instead of keeping render results in memory (would be a
cpu vs memory trade off), but that would have the disadvantage that your
model might have been changed between the last real render and the
render before ajax handling, resulting in a difference that would not be
regconized, and thus not sent to the browser to update the page.
Btw, any of you well versed javascript and willing to help?
And what do you think about the pattern? How would you like to see ajax
integrated?
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
