On Thu, Apr 12, 2012 at 7:26 AM, Dan Retzlaff <dretzl...@gmail.com> 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 
> <igor.vaynb...@gmail.com>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 <dretzl...@gmail.com> 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 <nsegu...@gmail.com>
>> wrote:
>> >
>> >> Sorry, you dont have to refresh 4 times, just once :p
>> >> -Nelson
>> >>
>> >> On Wed, Apr 11, 2012 at 6:08 PM, Nelson Segura <nsegu...@gmail.com>
>> 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: users-unsubscr...@wicket.apache.org
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to