You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Korbinian Bachl <ko...@whiskyworld.de> on 2007/10/30 17:51:34 UTC
Some question about wicket ajax
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? I know that we need a hook (namely an tag with id) but
couldnt this just be delegated to the next existing parent node?
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 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?
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)
Best,
Korbinian
Re: Some question about wicket ajax
Posted by Igor Vaynberg <ig...@gmail.com>.
none of us know if it will work until someone tries it :)
-igor
On 10/30/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> I know Igor :)
>
> but im currently in the situation where im not sure if it would work...
> furthermore, im not sure how to access the new generated page as well as
> accessing the old page (or better said: the markup of it)
>
> Igor Vaynberg schrieb:
> > a patch is welcome :)
> >
> > -igor
> >
> >
> > On 10/30/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> >> 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? I know that we need a hook (namely an tag with id) but
> >> couldnt this just be delegated to the next existing parent node?
> >>
> >> 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 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?
> >>
> >> 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)
> >>
> >> Best,
> >>
> >> Korbinian
> >>
> >
> >
>
Re: Some question about wicket ajax
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
I know Igor :)
but im currently in the situation where im not sure if it would work...
furthermore, im not sure how to access the new generated page as well as
accessing the old page (or better said: the markup of it)
Igor Vaynberg schrieb:
> a patch is welcome :)
>
> -igor
>
>
> On 10/30/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
>> 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? I know that we need a hook (namely an tag with id) but
>> couldnt this just be delegated to the next existing parent node?
>>
>> 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 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?
>>
>> 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)
>>
>> Best,
>>
>> Korbinian
>>
>
>
Re: Some question about wicket ajax
Posted by Igor Vaynberg <ig...@gmail.com>.
a patch is welcome :)
-igor
On 10/30/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> 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? I know that we need a hook (namely an tag with id) but
> couldnt this just be delegated to the next existing parent node?
>
> 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 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?
>
> 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)
>
> Best,
>
> Korbinian
>
Re: Some question about wicket ajax
Posted by Martijn Dashorst <ma...@gmail.com>.
no, but wicket does have wicket:enclosure to do what you want.
<wicket:enclosure>
<ul>
<li wicket:id="list"><span wicket:id="label"></span></li>
</ul>
</wicket:enclosure>
Martijn
On 10/31/07, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> Martijn Dashorst schrieb:
> > 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
>
> Ok, youre right - i got it now. Wicket hasn't got a Repeater with the
> behaviour I described?
>
> Thanks so far,
>
> 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/
Re: Some question about wicket ajax
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ko...@whiskyworld.de> 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 <ko...@whiskyworld.de> 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/
Re: Some question about wicket ajax
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
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 <ko...@whiskyworld.de> 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
>>>
>>>
>
>
Re: Some question about wicket ajax
Posted by Matej Knopp <ma...@gmail.com>.
On 10/31/07, Korbinian Bachl <ko...@whiskyworld.de> 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
> >
> >
> >
>
Re: Some question about wicket ajax
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Hi Matej,
> 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?
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?
> 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?
Thanks for your time to answer these questions,
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
>
>
>
Re: Some question about wicket ajax
Posted by Matej Knopp <ma...@gmail.com>.
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