Korbinian Bachl wrote / napísal(a):
Hi,
Hi
after creating yet another WebMarkupContainer to allow a ajaxified
resultset, i wondered why we are forced to this? - I mean, im not a JS
guru, but why do we have to create abstract containers to let some
content change?
You need to create container because repeaters in wicket don't produce
any markup. Only repeater children produce markup. So when you are
replacing a listview, you need an element in markup that demarcate what
you are replacing. Since listview itself has no body, you need a
container above it.
I know that we need a hook (namely an tag with id) but
couldnt this just be delegated to the next existing parent node?
What parent node. DOM parent node? That can't work in wicket, as the
parent node can be a part of RAW markup, which is not accessible for
performance reasons.
Or even further asked: wouldnt it be possible to have wicket do ajax
itself while we "users" just do a @ajaxify (just example, could be
similar to renderBody(bool)) prior to the webpage?
I'm not sure I follow
I mean, all wicket wouldt have to do is to render the result internal
and then compare the new result to the last rendered page (that should
be in wickets session afaik as we need it for BackButtonSupport), hook
up the not changed siblings of the HTML tree and swap the changed
contents... or Im thinking too easy here?
There is no last rendered page in wicket session. Why would we keep
rendered page in session? That can be huge (e.g. repeater with 10000 rows).
Also comparing two big DOM trees can be very expensive.
e.g:
Page old:
<body> content stable
<tag foo> content stable still </tag>
<tag foo2> content stable </tag>
</body>
Page New:
<body> content stable
<tag foo> content stable still </tag>
<tag foo3> new </tag>
</body>
-> comparing new to old: tag foo2 disappeared, so we send out an
ajaxrequest to clean these lines out, and put on that position a new tag
foo3 (after tag foo-endtag and prior to body-endtag)
But where would you get the previously rendered markup from? Keep it in
session? No way, that would be huge waste. Render it before changes to
page (in same request)? Then you'd render the entire page twice (instead
of just rendering one changed component). Also you'd have to parse the
page to a DOM (both of them actually) and compare them. I can't even
imagine what a huge waste of resources this would be.
Sorry for negative response, I just don't see any benefits that would
outweight the drawbacks.
-Matej
Best,
Korbinian
