Interesting, I didn't know it was possible to ask the component tree
which components wants to rerender. This could indeed answer to my
first point. But if I want finer grain component update (for
I build this my self. I know because of our design when components gets
new state or new data pushed. (our models do have things like Swing event
listeners)
repeaters), I guess the implementation would be a little bit more
complex: the repeating component would have to say "I want to
rerender, but only partially". Note that it would make it very easy
If the repeater component itself doesn't say it wants to rerender (because
its model changed)
but a component in the repeater component says it because his model did
change
then i have partial repeater updates just fine.
for wicket users to get an automatic refresh with fine grain: add an
instance of a behavior similar to the one you use now (which could be
part of wicket or wicket contrib, since it seems very generic), and
that's all. Then all you have to do is update your models, and they
will "magically" be updated on the client, with a limiting transport
when you insert a new sub component in a repeating view. Very nice.
It will be a bit hard for this to do in the standard wicket, because data is
pulled
not pushed. I only know it because data is pushed to the wicket models
and because i register the push (set a flag is changed) i know the next time
i have a rendering phase the component renders it self again.
ofcourse if cometd really would work that i could ask the container at some
point
for a connection again. Then i don't have to wait for the client timer event
but could push it directly.
But it's still opaque for me how the component know it has to be
refreshed. Indeed I'm surprised to see that the IModel interface
provides no way to get "observed" for changes. In a rich client
framework you always have such facility, which makes possible for a
component to know that its model has changed. And web 2.0 gets closer
and closer to the rich client world, so maybe this is something that
could be considered in wicket?
This is because of the rendering nature of the browser. (real pushing is
still
not really standard thing) But you could design it the way you like:
component->wicketmodel with event listener->your real datamodel.
johan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
