Chris Turner wrote:
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
Thought about that... would be perfect. How could we do that do though,
with our current 'pull' models?
2. Whenever we render a component we auto generate a dom id for it
which gets included in the output
Yep, we would need that regardless of the choosen strategy.
3. When an EventRequestHandler is invoked it can do whatever changes
to the page, component and/or models as necessary
That would mean that the request handlers must be pretty intelligent,
and that the scenario of implementing new ajax behaviour would be quite
ad-hoc. The more we can abstract, the easier it will be for people to
write their own ajax implementations.
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
What would this new output look like though? Probably a different output
than a normal render, right? And if that would be the case, it would
mean that components would have two seperate, independent means of
rendering which is something that I would like to avoid.
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
Ok, that could be an answer for 4.
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.
Sure. I'm all for as OO/ component centric as possible. Echo 2 has a
much simpler life in this, as they choose the all or nothing approach.
Wicket needs to support both ways of rendering.
The biggest hurdles I see are:
- How do we detect that a component needs re-rendering with our current
models? A partial answer to this is that I have been thinking that it
would be a good idea to standardize some 'propertyChange' like mechanism
on our models. Still, that would only really work for 'push' models.
- How do we implement this without ending up with components that do
their rendering in two different ways?
- One other thing I would like to avoid is to end up with a seperate
ajax enabled component tree. You should be able to 'enrich' components
with ajax behaviour, potentially with more behaviours a component. This
is why I came up with the 'handler' pattern. What do you think of that?
Eelco
regards,
Chris
-------------------------------------------------------
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
