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 < mlichtenb...@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 <dretzl...@gmail.com(mailto: > dretzl...@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 < > > > mlichtenb...@machenergy.com (mailto:mlichtenb...@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 <mlichtenb...@machenergy.com (mailto: > mlichtenb...@machenergy.com) (mailto: > > > > mlichtenb...@machenergy.com (mailto:mlichtenb...@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-unsubscr...@wicket.apache.org(mailto: > users-unsubscr...@wicket.apache.org) (mailto: > > > > > > > > > > > > > users-unsubscr...@wicket.apache.org (mailto: > users-unsubscr...@wicket.apache.org)) > > > > > For additional commands, e-mail: users-h...@wicket.apache.org(mailto: > users-h...@wicket.apache.org) (mailto: > > > > > > > > users-h...@wicket.apache.org (mailto:users-h...@wicket.apache.org)) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
