Have you actually tried the code you wrote? It would not output
<ul></ul>, it would not output anything. In fact if you add *two*
items to the list it would output:
<ul><li>foo</li></ul><ul><li>bar</li></ul>
Martijn
On 10/31/07, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> >> 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.
>
> sorry but i dont get it, if I do following:
> <ul wicket:id="list">
> <li wicket:id="somelabel">foo</li>
> </ul>
>
> add(new ListView("list", new ArrayList()) {
> public void onPopulateItem(ListItem item) {....}
> });
>
> it gives output:
>
> <ul></ul>
>
> if i have a list with 1 item it gives
> <ul><li>item</li></ul>
>
> so why isnt the UL then a valid hook?
>
> Best,
>
> Korbinian
>
> Matej Knopp schrieb:
> > 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
> >>>
> >>>
> >
> >
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/
