You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Nelson Segura <ns...@gmail.com> on 2012/04/12 02:52:47 UTC
Re: Page Map versions and Ajax Requests
I found the same problem, in my case it is page reload. I have a
simple QS that has a button that increments a counter using ajax. When
the user refreshes the page, the counter shows the correct number of
clicks. More clicks, and a new refresh, the counter shows as expected.
However, if I add an unrelated ListView to the same page, then page
refreshes do not reflect the clicks/ajax updates. This is because the
Ajax requests are going to a different version of the page as that one
being displayed. The list view is making the page dirty on each
refresh.
-nelson
On Fri, Dec 9, 2011 at 12:20 PM, Mark Lichtenberg
<ml...@machenergy.com> wrote:
> I'm seeing requests logged when the RequestLogger is enabled during page reloads and when the back button is used. The same code under 1.4 does not. I assumed the extra request was to fetch the latest render of the page if it was updated via ajax.
>
> On Friday, December 9, 2011 at 1:59 PM, Dan Retzlaff wrote:
>
>> I wouldn't say there are extra requests, just extra page versions due to
>> re-population of the list view. Seems like the re-population process should
>> be engineered in a way that doesn't advance the page number. But I'll leave
>> that to the experts. :)
>>
>> On Fri, Dec 9, 2011 at 11:50 AM, Mark Lichtenberg <
>> mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com)> wrote:
>>
>> > That's exactly what I'm experiencing. In 1.5 it appears there's a few
>> > extra requests during a reload that I assume are retrieving the latest page
>> > version. I'll create a bug report. Thanks for your help.
>> >
>> > Mark
>> >
>> > On Friday, December 9, 2011 at 1:26 PM, Dan Retzlaff wrote:
>> > > I confirmed this behavior in our application. Simply reloading a page
>> >
>> > with
>> > > a ListView a few times advances the page ID but not the URL. AJAX links
>> > > know to target the new page ID, but any updates they make get lost if the
>> > > page gets reloaded from the URL. Sounds like a bug to me. Wicket 1.4
>> > >
>> >
>> > didn't
>> > > behave this way.
>> > >
>> > > On Fri, Dec 9, 2011 at 10:26 AM, Dan Retzlaff <dretzlaff@gmail.com (mailto:dretzlaff@gmail.com)(mailto:
>> > dretzlaff@gmail.com (mailto:dretzlaff@gmail.com))> wrote:
>> > >
>> > > > Without reusing the ListView items, the "item.add(...)" will get called
>> > > > with each render. I expect that'll cause
>> > > >
>> > >
>> > >
>> >
>> > MarkupContainer#addedComponent()
>> > > > to WebPage#componentAdded() to WebPage#dirty() which sets a new page
>> > >
>> >
>> > ID.
>> > > > Sorry I don't have time to test the theory at the moment.
>> > > >
>> > > >
>> > > > On Fri, Dec 9, 2011 at 8:27 AM, Mark Lichtenberg <
>> > > > mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com)>
>> > > >
>> > >
>> >
>> > wrote:
>> > > >
>> > > > > 1.5.3.
>> > > > >
>> > > > > I've narrowed the problem to a ListView being present on the page.
>> > > > > Whenever there's a ListView with setReuseItems set to false (the
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>> > default)
>> > > > > the Page ID gets incremented whenever the back button is used to
>> > > >
>> > >
>> >
>> > return to
>> > > > > the page. I confirmed this with a call to getPage().getPageId() in an
>> > > > > onComponentTag method. After returning via the back button the URL
>> > > > >
>> > > >
>> > >
>> >
>> > is still
>> > > > > at the original Page ID while there's a newer version in the page
>> > > >
>> > >
>> >
>> > map.
>> > > > >
>> > > > > Without a ListView present on the page using the back button does not
>> > > > > increment the Page ID and everything works as expected.
>> > > > >
>> > > > > I have a quickstart app that illustrates the problem. Here is the
>> > page
>> > > > > with the applicable code: http://pastebin.com/jn9czHK8
>> > > > >
>> > > > > Mark
>> > > > >
>> > > > >
>> > > > > On Friday, December 9, 2011 at 9:56 AM, Nazaret Kazarian wrote:
>> > > > > > Which version of Wicket are you using?
>> > > > > >
>> > > > > >
>> > > > > > 2011/12/7 Lichtenberg, Mark <mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com) (mailto:
>> > mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com)) (mailto:
>> > > > > mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com))>:
>> > > > > > > I have a page containing a number of AjaxLinks that when clicked
>> > > > > >
>> > > > >
>> > > > >
>> > > > > fetch data
>> > > > > > > and update some panels. When a user leaves one of these pages and
>> > > > > >
>> > > > >
>> > > > >
>> > > > > returns
>> > > > > > > via the back button the state of the page isn't always how they
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > left
>> > > > > >
>> > > > >
>> > > > >
>> > > > > it.
>> > > > > > > However, this behavior happens only when the page is returned to
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > the
>> > > > > >
>> > > > >
>> > > > >
>> > > > > second
>> > > > > > > time. Using the the request logger I've been able to partially
>> > > > > >
>> > > > >
>> > > > >
>> > > > > explain this
>> > > > > > > with the page IDs:
>> > > > > > >
>> > > > > > >
>> > > > > > > 1. First visit to page X has a page ID of 3
>> > > > > > > 2. AjaxLink requests for this page also have a page ID of 3.
>> > > > > > > 3. User leaves page then returns to page X via the back button;
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > this
>> > > > > > > request also has ID of 3
>> > > > > > > 4. User clicks AjaxLinks again, but here a new X page is created
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > with an
>> > > > > > > ID of 5
>> > > > > > > 5. User leaves page and again returns with the back button. Here
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > the
>> > > > > > > page state is as they left it in #2, and the URL confirms the
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > page
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > ID of 3
>> > > > > > >
>> > > > > > > I understand using the back button will always take the user to
>> > ID 3
>> > > > > since
>> > > > > > > it is present in the URL.
>> > > > > > >
>> > > > > > > My workaround so far is to add the Page component to the target
>> > of my
>> > > > > > > AjaxLink onClick()s. This increments the page ID whenever an
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > AjaxLink
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > is
>> > > > > > > clicked and is reflected in the URL, so the back button always
>> > > > > >
>> > > > >
>> > > > >
>> > > > > returns to
>> > > > > > > the last state.
>> > > > > > >
>> > > > > > > So I have two questions - Why is a new page X created in step 4
>> > > > > above, and
>> > > > > > > why does adding the Page component to the ajax request target
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> > make a
>> > > > > >
>> > > > >
>> > > > >
>> > > > > new
>> > > > > > > page map entry?
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > Mark
>> > ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org (mailto:users-unsubscribe@wicket.apache.org)(mailto:
>> > > > >
>> > > >
>> > >
>> >
>> > users-unsubscribe@wicket.apache.org (mailto:users-unsubscribe@wicket.apache.org)) (mailto:
>> > > > > >
>> > > > >
>> > > > >
>> > > > > users-unsubscribe@wicket.apache.org (mailto:users-unsubscribe@wicket.apache.org) (mailto:
>> > users-unsubscribe@wicket.apache.org (mailto:users-unsubscribe@wicket.apache.org)))
>> > > > > > For additional commands, e-mail: users-help@wicket.apache.org (mailto:users-help@wicket.apache.org)(mailto:
>> > > > >
>> > > >
>> > >
>> >
>> > users-help@wicket.apache.org (mailto:users-help@wicket.apache.org)) (mailto:
>> > > > >
>> > > > > users-help@wicket.apache.org (mailto:users-help@wicket.apache.org))
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> >
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page Map versions and Ajax Requests
Posted by Dan Retzlaff <dr...@gmail.com>.
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 <ig...@gmail.com>wrote:
> On Thu, Apr 12, 2012 at 7:26 AM, Dan Retzlaff <dr...@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.vaynberg@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 <dr...@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 <ns...@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 <ns...@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-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Page Map versions and Ajax Requests
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Apr 12, 2012 at 7:26 AM, Dan Retzlaff <dr...@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 <ig...@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 <dr...@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 <ns...@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 <ns...@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-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page Map versions and Ajax Requests
Posted by Dan Retzlaff <dr...@gmail.com>.
Your second suggestion seems pretty solid, but I think people do make
non-trivial component hierarchy changes in onBeforeRender. 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.
On Wed, Apr 11, 2012 at 11:47 PM, Igor Vaynberg <ig...@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 <dr...@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 <ns...@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 <ns...@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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Page Map versions and Ajax Requests
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <dr...@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 <ns...@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 <ns...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page Map versions and Ajax Requests
Posted by Dan Retzlaff <dr...@gmail.com>.
> 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 <ns...@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 <ns...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Page Map versions and Ajax Requests
Posted by Nelson Segura <ns...@gmail.com>.
Sorry, you dont have to refresh 4 times, just once :p
-Nelson
On Wed, Apr 11, 2012 at 6:08 PM, Nelson Segura <ns...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page Map versions and Ajax Requests
Posted by Nelson Segura <ns...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Page Map versions and Ajax Requests
Posted by Dan Retzlaff <dr...@gmail.com>.
Yeah, that sounds like the same issue:
https://issues.apache.org/jira/browse/WICKET-4286
On Wed, Apr 11, 2012 at 6:52 PM, Nelson Segura <ns...@gmail.com> wrote:
> I found the same problem, in my case it is page reload. I have a
> simple QS that has a button that increments a counter using ajax. When
> the user refreshes the page, the counter shows the correct number of
> clicks. More clicks, and a new refresh, the counter shows as expected.
> However, if I add an unrelated ListView to the same page, then page
> refreshes do not reflect the clicks/ajax updates. This is because the
> Ajax requests are going to a different version of the page as that one
> being displayed. The list view is making the page dirty on each
> refresh.
> -nelson
>
> On Fri, Dec 9, 2011 at 12:20 PM, Mark Lichtenberg
> <ml...@machenergy.com> wrote:
> > I'm seeing requests logged when the RequestLogger is enabled during page
> reloads and when the back button is used. The same code under 1.4 does not.
> I assumed the extra request was to fetch the latest render of the page if
> it was updated via ajax.
> >
> > On Friday, December 9, 2011 at 1:59 PM, Dan Retzlaff wrote:
> >
> >> I wouldn't say there are extra requests, just extra page versions due to
> >> re-population of the list view. Seems like the re-population process
> should
> >> be engineered in a way that doesn't advance the page number. But I'll
> leave
> >> that to the experts. :)
> >>
> >> On Fri, Dec 9, 2011 at 11:50 AM, Mark Lichtenberg <
> >> mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com)>
> wrote:
> >>
> >> > That's exactly what I'm experiencing. In 1.5 it appears there's a few
> >> > extra requests during a reload that I assume are retrieving the
> latest page
> >> > version. I'll create a bug report. Thanks for your help.
> >> >
> >> > Mark
> >> >
> >> > On Friday, December 9, 2011 at 1:26 PM, Dan Retzlaff wrote:
> >> > > I confirmed this behavior in our application. Simply reloading a
> page
> >> >
> >> > with
> >> > > a ListView a few times advances the page ID but not the URL. AJAX
> links
> >> > > know to target the new page ID, but any updates they make get lost
> if the
> >> > > page gets reloaded from the URL. Sounds like a bug to me. Wicket 1.4
> >> > >
> >> >
> >> > didn't
> >> > > behave this way.
> >> > >
> >> > > On Fri, Dec 9, 2011 at 10:26 AM, Dan Retzlaff <dretzlaff@gmail.com(mailto:
> dretzlaff@gmail.com)(mailto:
> >> > dretzlaff@gmail.com (mailto:dretzlaff@gmail.com))> wrote:
> >> > >
> >> > > > Without reusing the ListView items, the "item.add(...)" will get
> called
> >> > > > with each render. I expect that'll cause
> >> > > >
> >> > >
> >> > >
> >> >
> >> > MarkupContainer#addedComponent()
> >> > > > to WebPage#componentAdded() to WebPage#dirty() which sets a new
> page
> >> > >
> >> >
> >> > ID.
> >> > > > Sorry I don't have time to test the theory at the moment.
> >> > > >
> >> > > >
> >> > > > On Fri, Dec 9, 2011 at 8:27 AM, Mark Lichtenberg <
> >> > > > mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com)>
> >> > > >
> >> > >
> >> >
> >> > wrote:
> >> > > >
> >> > > > > 1.5.3.
> >> > > > >
> >> > > > > I've narrowed the problem to a ListView being present on the
> page.
> >> > > > > Whenever there's a ListView with setReuseItems set to false (the
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >> > default)
> >> > > > > the Page ID gets incremented whenever the back button is used to
> >> > > >
> >> > >
> >> >
> >> > return to
> >> > > > > the page. I confirmed this with a call to getPage().getPageId()
> in an
> >> > > > > onComponentTag method. After returning via the back button the
> URL
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > is still
> >> > > > > at the original Page ID while there's a newer version in the
> page
> >> > > >
> >> > >
> >> >
> >> > map.
> >> > > > >
> >> > > > > Without a ListView present on the page using the back button
> does not
> >> > > > > increment the Page ID and everything works as expected.
> >> > > > >
> >> > > > > I have a quickstart app that illustrates the problem. Here is
> the
> >> > page
> >> > > > > with the applicable code: http://pastebin.com/jn9czHK8
> >> > > > >
> >> > > > > Mark
> >> > > > >
> >> > > > >
> >> > > > > On Friday, December 9, 2011 at 9:56 AM, Nazaret Kazarian wrote:
> >> > > > > > Which version of Wicket are you using?
> >> > > > > >
> >> > > > > >
> >> > > > > > 2011/12/7 Lichtenberg, Mark <mlichtenberg@machenergy.com(mailto:
> mlichtenberg@machenergy.com) (mailto:
> >> > mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com))
> (mailto:
> >> > > > > mlichtenberg@machenergy.com (mailto:mlichtenberg@machenergy.com
> ))>:
> >> > > > > > > I have a page containing a number of AjaxLinks that when
> clicked
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > fetch data
> >> > > > > > > and update some panels. When a user leaves one of these
> pages and
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > returns
> >> > > > > > > via the back button the state of the page isn't always how
> they
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > left
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > it.
> >> > > > > > > However, this behavior happens only when the page is
> returned to
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > the
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > second
> >> > > > > > > time. Using the the request logger I've been able to
> partially
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > explain this
> >> > > > > > > with the page IDs:
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > 1. First visit to page X has a page ID of 3
> >> > > > > > > 2. AjaxLink requests for this page also have a page ID of 3.
> >> > > > > > > 3. User leaves page then returns to page X via the back
> button;
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > this
> >> > > > > > > request also has ID of 3
> >> > > > > > > 4. User clicks AjaxLinks again, but here a new X page is
> created
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > with an
> >> > > > > > > ID of 5
> >> > > > > > > 5. User leaves page and again returns with the back button.
> Here
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > the
> >> > > > > > > page state is as they left it in #2, and the URL confirms
> the
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > page
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > ID of 3
> >> > > > > > >
> >> > > > > > > I understand using the back button will always take the
> user to
> >> > ID 3
> >> > > > > since
> >> > > > > > > it is present in the URL.
> >> > > > > > >
> >> > > > > > > My workaround so far is to add the Page component to the
> target
> >> > of my
> >> > > > > > > AjaxLink onClick()s. This increments the page ID whenever an
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > AjaxLink
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > is
> >> > > > > > > clicked and is reflected in the URL, so the back button
> always
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > returns to
> >> > > > > > > the last state.
> >> > > > > > >
> >> > > > > > > So I have two questions - Why is a new page X created in
> step 4
> >> > > > > above, and
> >> > > > > > > why does adding the Page component to the ajax request
> target
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > make a
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > new
> >> > > > > > > page map entry?
> >> > > > > > >
> >> > > > > > > Thanks,
> >> > > > > > >
> >> > > > > > > Mark
> >> > ---------------------------------------------------------------------
> >> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org(mailto:
> users-unsubscribe@wicket.apache.org)(mailto:
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > users-unsubscribe@wicket.apache.org (mailto:
> users-unsubscribe@wicket.apache.org)) (mailto:
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > users-unsubscribe@wicket.apache.org (mailto:
> users-unsubscribe@wicket.apache.org) (mailto:
> >> > users-unsubscribe@wicket.apache.org (mailto:
> users-unsubscribe@wicket.apache.org)))
> >> > > > > > For additional commands, e-mail: users-help@wicket.apache.org(mailto:
> users-help@wicket.apache.org)(mailto:
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> > users-help@wicket.apache.org (mailto:users-help@wicket.apache.org))
> (mailto:
> >> > > > >
> >> > > > > users-help@wicket.apache.org (mailto:
> users-help@wicket.apache.org))
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>