Re: refresh and AjaxFallbackDefaultDataTable
> > Can't you fix that with a > getPage().dirty(); > in the Ajax request handler? Hmm tried your suggestion, but no luck. How would it help anyway? It's dirty() that is causing the page to change version in the first place right? RefreshingView.onPopulate() -> MarkupContainer.removeAll() -> Component.addStateChange() -> Page.componentStateChanging() -> Page.dirty() -> new version number! I did find a fix for this though. Changing the rendering strategy from the default REDIRECT_TO_BUFFER to ONE_PASS_RENDER. With this strategy, the initial request is not redirect to "*?%version%*", which means when the user presses refresh, a new page is recreated from scratch every time. Ajax updates are applied on the version of the page that originally rendered them, so there's no ambiguity like the scenario I describe. The drawback of course is that page refreshes lose ajax updates, but the semantic in that case at least is very clear and it's what I expected in the first place. On Tue, Feb 14, 2012 at 7:32 AM, Wilhelmsen Tor Iver wrote: > > Thus the browser still shows the old version in the URL. But all future > Ajax requests are targetting a different page version than visible in the > browser URL :(. > > Can't you fix that with a > > getPage().dirty(); > > in the Ajax request handler? > > - Tor Iver > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
RE: refresh and AjaxFallbackDefaultDataTable
> Thus the browser still shows the old version in the URL. But all future Ajax > requests are targetting a different page version than visible in the browser > URL :(. Can't you fix that with a getPage().dirty(); in the Ajax request handler? - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: refresh and AjaxFallbackDefaultDataTable
Hi, in Ajax requests the page id is not incremented, to keep the page version in the browser's url in sync with the state on the server. When the page is refreshed (F5), the following happens: - WebPageRenderer#respond() checks whether the url has changed, which it has not yet. So no redirect seems necessary. - while rendering (more correctly in onBeforeRender()) the DataView removes all its children, thus resulting in a version increment - all links render itself with the new page version Thus the browser still shows the old version in the URL. But all future Ajax requests are targetting a different page version than visible in the browser URL :(. Sven Am 13.02.2012 20:13, schrieb Jonathan Tougas: I'm getting some inconsistent behavior with AjaxFallbackDefaultDataTable. Here are two scenarios that can be run on wicket-examples: *Scenario 1* 1 - navigate to http://wicketstuff.org/wicket/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.AjaxDataTablePage 2 - click the link to navigate to page 2 3 - refresh (F5) After the page refresh, you're still on page 2 - as expected *Scenario 2:* 1 - navigate to http://wicketstuff.org/wicket/repeater/wicket/bookmarkable/org.apache.wicket.examples.repeater.AjaxDataTablePage 2 - refresh (F5) 3 - click the link to navigate to results page 2 4 - refresh (F5) After the page refresh you're back to page 1 - oops The navigation links work fine until the page is refreshed. After a page refresh the navigation links point to the wrong page version (or so it seems), so refreshing a second time doesn't work as expected. I'm fairly new to Wicket so I may be missing something, and I haven't found a bug report for this. Can someone confirm or explain what I"m not getting please? Cheers! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org