I was thinking the same "freeze" pattern could be applied in the other repeaters configured to throw away their content. But the "no action phase => no version increment" rule is simpler to explain, and probably more fool-proof.
On Thu, Apr 12, 2012 at 8:38 AM, Igor Vaynberg <[email protected]>wrote: > On Thu, Apr 12, 2012 at 7:26 AM, Dan Retzlaff <[email protected]> wrote: > > Your second suggestion seems pretty solid, but I think people do make > > non-trivial component hierarchy changes in onBeforeRender. > > my point was that such changes are not worthy of a page version > increment because they can be safely thrown away since they are > regenerated every render. > > > Why not just > > freeze the page version during rendering of reuseItems=false ListViews? > You > > know the content will be thrown away so a new page version doesn't seem > > appropriate. > > because that is not enough. what about RefreshingViews? what about > DataViews? what about custom repeaters that users wrote by extending > RepeatingView? what about other code that changes hierarchy in > onBeforeRender(). > > even code like this would cause the same break: > > onBeforeRender() { > addOrReplace(new Label("time", new Date())); > } > > this needs to be handled at a higher level... > > -igor > > > > > > On Wed, Apr 11, 2012 at 11:47 PM, Igor Vaynberg <[email protected] > >wrote: > > > >> whats happening is this > >> > >> user hits the page /foo > >> goes to /foo?1 > >> does a bunch of ajax stuff, staying on /foo?1 > >> clicks refresh, so hits /foo?1 > >> listview refreshes, changing hierarchy, creating page version 2 > >> the ajax behavior's url is rendered as /foo?2:... > >> the page is rendered, but not redirected to /foo?2 > >> > >> so what we have now is a browser pointing to /foo?1 and ajax (and > >> non-ajax) urls pointing to /foo?2 > >> > >> further clicks work only because the component they repaint has the > >> same markup id on page 1 and page 2. however, all model changes are > >> stored in page 2. this is why when the browser is refreshed the > >> counter reverts to a previous value - because it is page 1 that is > >> rerendered. > >> > >> there are two ways to fix this: > >> > >> 1) redirect to correct version. so when the browser is refreshed for > >> the first time on /foo?1 the browser would redirect to /foo?2 and it > >> would keep doing that for every refresh. not ideal. > >> > >> 2) freeze the page version when we are accessing a url that we know > >> will not mutate the state of the page - meaning urls that just render > >> the page and do not invoke any listeners. the only state we will lose > >> is noise from component replacement in listviews and user's > >> onbeforerender() overrides which i think is acceptable since they do > >> not represent true state mutation that comes from intentional > >> callbacks. > >> > >> -igor > >> > >> > >> On Wed, Apr 11, 2012 at 6:40 PM, Dan Retzlaff <[email protected]> > wrote: > >> >> I don't know exactly what is making the page dirty in this case. > >> > > >> > The AJAX debug window has a ListView in it. > >> > > >> > On Wed, Apr 11, 2012 at 7:09 PM, Nelson Segura <[email protected]> > >> wrote: > >> > > >> >> Sorry, you dont have to refresh 4 times, just once :p > >> >> -Nelson > >> >> > >> >> On Wed, Apr 11, 2012 at 6:08 PM, Nelson Segura <[email protected]> > >> wrote: > >> >> > This is easily reproduceable in the wicket sample pages: > >> >> > > >> >> > http://www.wicket-library.com/wicket-examples/ajax/links > >> >> > > >> >> > 1. Click on the increment link for Counter 2 for times. Counter > shows > >> 4. > >> >> > 2. CTRL-R/refresh 4 times, the counter still shows 4. > >> >> > 3. Click on link 4 more times. Counter shows 8 > >> >> > 4.CTRL-R/refresh once more, the counter shows 4! > >> >> > > >> >> > I don't know exactly what is making the page dirty in this case. > >> >> > > >> >> > Can you confirm this behavior in the sample page? > >> >> > > >> >> > -Nelson > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
