Eelco Hillenius wrote:
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?
We would probably need to expand the models in some way to support some
form of dirty checking - be that automatic or manual, property change
listeners or dirty flags or whatever. Not sure exactly how we would
achieve this, but I think we have to solve this problem if we want ajax
support to be a reality. This is the biggest challenge for Wicket 1.1 in
my opinion.
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.
Why do request handler need to be more intelligent than existing event
handlers - they are doing exactly the same thing: reacting to events.
Where the added complexity comes in is in the model objects as these
need someone waht to support change detection.
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.
No, this is the beauty of the approach. Each component only has one way
of rendering. The difference being that for Page rendering we are
including it into the combined page response, whereas for AJAX rendering
we are just building a map of the components DOM it to the small piece
of HTML rendering for that component. The HTML for the component should
be exactly the same, if just how it is used that is different.
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.
Yes, we need to make out models more intelligent. Wicket models are
currntly just a convenient way to bridge between Wicket components and
POJOs. This is fine for non-ajax, but for AJAX support they need to
become a bit clever!
- 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 e 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?
Yes, we must only have one component tree. However, what we need to do
is AJAX enable the existing components rather than have AJAX alternatives.
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
-------------------------------------------------------
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
