Re: updating page version after an ajax request
I'm waiting for a long time for the resolution of this bug wich is very important in regards on the use of Ajax nowadays. Unfortunately, the resolution has always been delayed and I don't know enough Wicket to try to resolve it. :( 2010/9/17 Josh Kamau > hello, Is there a way of updating the page version after an ajax request in > order to support the back button for a 100% component based application > (i.e > an application based on a single page)? > > i think my question is related to this > https://issues.apache.org/jira/browse/WICKET-271. > > Has any of the 1.5 milestones implemented this? > > kind regards. > Josh >
Re: updating page version after an ajax request
I wont say this is a bug. Actually it is by design. When the page renders all links' href url points to specific page version. So when the user clicks on any link the page is properly resolved and the click processed. If you change the page id with Ajax then there is a chance to leave broken links/forms in the page. Clicking on those will result in either using old version of the page or even worse PageExpiredException. Anyway, if you still want to do that then extend org.apache.wicket.protocol.http.SecondLevelCacheSessionStore and hack around in org.apache.wicket.protocol.http.SecondLevelCacheSessionStore.SecondLevelCachePageVersionManager. You may need to copy/paste the whole stuff in your own class. Finally override org.apache.wicket.protocol.http.WebApplication.newSessionStore() to use your class. martin-g The destiny loves the braves! On Fri, Sep 17, 2010 at 1:35 PM, Gaetan Zoritchak < g.zoritc...@virtual-soft.com> wrote: > I'm waiting for a long time for the resolution of this bug wich is very > important in regards on the use of Ajax nowadays. Unfortunately, the > resolution has always been delayed and I don't know enough Wicket to try to > resolve it. :( > > 2010/9/17 Josh Kamau > > > hello, Is there a way of updating the page version after an ajax request > in > > order to support the back button for a 100% component based application > > (i.e > > an application based on a single page)? > > > > i think my question is related to this > > https://issues.apache.org/jira/browse/WICKET-271. > > > > Has any of the 1.5 milestones implemented this? > > > > kind regards. > > Josh > > >
Re: updating page version after an ajax request
On Fri, Sep 17, 2010 at 3:04 PM, Martin Grigorov wrote: > I wont say this is a bug. > Actually it is by design. > When the page renders all links' href url points to specific page version. > So when the user clicks on any link the page is properly resolved and the > click processed. > If you change the page id with Ajax then there is a chance to leave broken > links/forms in the page. Clicking on those will result in either using old > version of the page or even worse PageExpiredException. Couldn't we use a cookie to keep the current version/tab/window? we could update it serverside and clientside to our liking... Not sure how we could hook into the back button for that though... One thing is sure: when using ajax, javascript works... Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: updating page version after an ajax request
May be you could provide the developer with access to the page history utilities such that i can update the version of the current page at will or leave things to work normally if i dont want to break anything. something like thisPage.getVersion().increment() ; regards. On Fri, Sep 17, 2010 at 6:03 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Fri, Sep 17, 2010 at 3:04 PM, Martin Grigorov > wrote: > > I wont say this is a bug. > > Actually it is by design. > > When the page renders all links' href url points to specific page > version. > > So when the user clicks on any link the page is properly resolved and the > > click processed. > > If you change the page id with Ajax then there is a chance to leave > broken > > links/forms in the page. Clicking on those will result in either using > old > > version of the page or even worse PageExpiredException. > > Couldn't we use a cookie to keep the current version/tab/window? we > could update it serverside and clientside to our liking... Not sure > how we could hook into the back button for that though... > > One thing is sure: when using ajax, javascript works... > > Martijn > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: updating page version after an ajax request
the problem with "updating the version of the page" is that all urls in the page, be in hrefs or in javascript, have to be rewritten with the new page version... -igor On Tue, Sep 21, 2010 at 2:19 AM, Josh Kamau wrote: > May be you could provide the developer with access to the page history > utilities such that i can update the version of the current page at will or > leave things to work normally if i dont want to break anything. something > like thisPage.getVersion().increment() ; > > regards. > > On Fri, Sep 17, 2010 at 6:03 PM, Martijn Dashorst < > martijn.dasho...@gmail.com> wrote: > >> On Fri, Sep 17, 2010 at 3:04 PM, Martin Grigorov >> wrote: >> > I wont say this is a bug. >> > Actually it is by design. >> > When the page renders all links' href url points to specific page >> version. >> > So when the user clicks on any link the page is properly resolved and the >> > click processed. >> > If you change the page id with Ajax then there is a chance to leave >> broken >> > links/forms in the page. Clicking on those will result in either using >> old >> > version of the page or even worse PageExpiredException. >> >> Couldn't we use a cookie to keep the current version/tab/window? we >> could update it serverside and clientside to our liking... Not sure >> how we could hook into the back button for that though... >> >> One thing is sure: when using ajax, javascript works... >> >> Martijn >> >> - >> 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
