On 10/31/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> Hi Matej,
>
Hi
> > Sorry for negative response, I just don't see any benefits that would
> > outweight the drawbacks.
>
> no need to be sorry. That was exactly what I hoped to come. If sb. has a
> new Idea, he believes its good and usually dont see all drawbacks - then
> its good to have somebody else coming and slicing the bad things apart
> and tell it :)
>
> So, as far as I understood, wicket doesnt save any rendered page, so how
> is the BackButton support handled then?
Wicket saves a snapshot of page state. But that is serialized
component tree. Not the actual rendered output. It is bunch of
component instances instead of a html file.
>
> And regarding the RAW marup: that was new for me... I expected wicket
> knows this as it immediately throws out an error if you have some wrong
> closing tags - how is this checked?
This is checked during markup parsing. But when wicket parses markup,
it glues non-wicket tags (tags without wicket:id) together to a blocks
called RawMarkup. This is done for performance reasons - it makes
rendering faster, otherwise we would have tons of small non-wicket
tags that we had to iterate through in markup stream.
>
> > 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.
>
> this is something I understand for RepeatingView, but not for ListView -
> where you have an enclosing tag which is put around all repeated content?
But where do you have that tag in list view?
<li wicket:id="list">
content...
</li>
add(new ListView("list") {
public void onPopulateItem(ListItem item) { ... };
});
this does seem like the <li> is an element attached to list view, but
that's not true. Actually each generated list item is attached to the
<li>. The actual ListView produces no output, only the items.
>
> Thanks for your time to answer these questions,
Sure!
-Matej
>
> Korbinian
>
>
> Matej Knopp schrieb:
> > 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
> >
> >
> >
>
