none of us know if it will work until someone tries it :) -igor
On 10/30/07, Korbinian Bachl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >> > > > > >
