I had always though of it happening in a slightly different way:
1. Each component has some way of knowing whether there has been some
change that will cause its rendered output to be different
2. Whenever we render a component we auto generate a dom id for it which
gets included in the output
3. When an EventRequestHandler is invoked it can do whatever changes to
the page, component and/or models as necessary
4. Finally we visit each of the components on the page and ask any that
know their rendered output to be different to supply their new output
5. We then send a document back with the new output for each component
associated with the DOM id. The javascript then looks up each element by
id and changes its innerHTML to the returned markup
This requires no changes in the way people use Wicket. Most changes are
encapsulated in the components, which is where this information should
logically live. Additionally, the Javascript library for receiving AJAX
responses and doing the page render is very small and simple.
You can also implement some very clever logic such that if a container
and a component in that container change then we only need send the new
rendered content for the panel (as this will include the new content for
the component).
By default, Wicket can try to manage the change detection, but it could
also be over ridable so any developer need only get a component and set
its re-render flag to true within the EventRequestHandler.
I think this is much more 'object-oriented' and 'component centric' than
trying to rerender pages and compare string buffers and the like. I also
believe that this approach is very similar to that taken by Echo2.
regards,
Chris
Eelco Hillenius wrote:
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
-------------------------------------------------------
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
