Hi Chris,
Wicket-Ajax discussion is about 2 months old, not to much has happened
and seems to gain momentum just now, recap:
-you wrote the Wiki page
-Eelco and I did some changes to Wiki page
-Johan did a first commit for use of Ajax in wicket
-Eelco did improve on first commit (testing listeners)
-we discussed some approaches how to deal with AJAX in a generic way at
JavaOne
-3 threads on dev-mailing list so far
From the threads/Wiki/discussions we now have 3 ideas/strategies to do
AJAX in a generic manner:
1) partial re-rendering of page when Ajax invoke is done (Chris)
2) JavaScript lib which renders components property changes when Ajax
invoke is done (Johan/Jan)
3) full page re render and page difference returning when Ajax invoke is
done (Eelco)
Similarities between 1 and 2:
-components have notion of Ajax render phase (visiting all components on
page after Ajax-listener invoke)
-components have some way of knowing whether there has been some change
on them
-components know there JavaScript id or generate one if none present
Drawback I foresee for 1 and 2 when using/wrapping JSF components in
(near) future, they cannot handle changes generated by those JSF
components when altered somehow as result of AJAX invoke on wicket
components
Drawback seen for 1 and 3 is when having edited values in some html form
fields which not yet have been submitted and an Ajax call replaces the
entire field to only modify a property (with innerHTML) due to some
other validation action.
Drawback for 2 (quite some work to get the JavaScript change lib.
right/complete)
So far it seems that all the discussion is about how/where to store the
differences between separate renderer cycles (normal or AJAX), after
some discussion with Johan it seems best to leave it to the component
which strategy to use for an Ajax render phase, we only should support
the strategies (and implement a default one for each) therefor:
-a component should have the notion it is being Ajax rendered
-it should have access to a (optimized)storage to store its previous
(partial)value (its true dynamic part) or other Dom properties changes
-it should have access to a JavaScript change generation lib.
-it should have access to its own full rendering output (after a
rendering, to be used for innerHTML)
-it should have the possibility to do a full normal rendering of it
self during an Ajax render-phase (to support innerHTML)
-we should define a specification how changes are returned to browser in
case of Ajax render-phase
-a component should have/get its JavaScript id
With this scenario we can:
-do simple changes in for example on choices/labels via JavaScript
-do full component replace via innerHTML/JavaScript when the component
thinks it the best approach (makes it also possible to track changes
from external web components like JSF), also Eelco his idea to store
full page render diffs is more fine grained to component level instead
of page level.
-no need to change the model (interfaces) or build observers
Regards Jan Blok
Chris Turner wrote:
If it's not too much trouble would someone be able to write up a
brief overview of all the discussions that have been had, avenues that
have been explored and so on so that I am able to start afresh with a
full picture of how we got to where we are at the moment.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
