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 < > [email protected] (mailto:[email protected])> 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 <[email protected] > > > (mailto:[email protected])(mailto: > > [email protected] (mailto:[email protected]))> 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 < > > > > [email protected] (mailto:[email protected])> > > > > > > > > > > > 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 <[email protected] > > > > > > (mailto:[email protected]) (mailto: > > [email protected] (mailto:[email protected])) (mailto: > > > > > [email protected] (mailto:[email protected]))>: > > > > > > > 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: [email protected] > > > > > > (mailto:[email protected])(mailto: > > > > > > > > > > > > > > > > [email protected] > > (mailto:[email protected])) (mailto: > > > > > > > > > > > > > > > > > > > > > [email protected] > > > > > (mailto:[email protected]) (mailto: > > [email protected] > > (mailto:[email protected]))) > > > > > > For additional commands, e-mail: [email protected] > > > > > > (mailto:[email protected])(mailto: > > > > > > > > > > > > > > > > [email protected] (mailto:[email protected])) (mailto: > > > > > > > > > > [email protected] (mailto:[email protected])) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
