Re: Wicket back button behavior
Hmmm, it's not quite PERFECTLY what I was after, but it may be "close enough". When I go back, I am still taken to previous pages by virtue of the mounted URLs, but I am no longer being taken to old VERSIONS of those pages, which was the main problem. I'll have to check with my requirements team to verify that this is close enough. Thanks for the suggestion and quick reply! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-back-button-behavior-tp4677587p4677651.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket back button behavior
Hi, If I get you right, you want to be able to have some pages that always display their last state, right? What about trying the "Wicket no version mapper" pattern? [1] For you, getting rid of the version number in the URL is just a side-effect, but it should do the trick. Plus, you can switch it on or off on a per-page basis. Sorry if I misunderstood you. Regards, Zala 1: http://stackoverflow.com/questions/8602489/delete-version-number-in-url On Mon, Apr 10, 2017 at 8:08 PM, Entropy wrote: > I am trying to set this up. I looked at some docs and I feel like > creating a > custom PageManager seems like what I want to do. The thing is, no matter > how I implement the getPage(int), the Wicket app behaves the same. The > back > button still does it's default behavior every time. > > Here's what I did. I capture the maximum page in touchPage(), and then > getPage() returns it. When I hit back during my process flow, initially I > get a bunch of calls to getPage() which dutifully returns the currentPage I > want. But then, after that, touchPage is called with the prior page (the > one the user is going BACK to). What's more, it's called with an ID one > GREATER than the maximum page ID as returned in getPage(). > > getPage() is never called again in that request, and the app then renders > the prior page, as if it ignored what getPage() returned. It's like I am > missing an additional change setting that would make touchPage() cooperate. > > I also tried raising a RestartResponseException from within the PageManager > when BACK was hit, but that just got me sent to the error page. > > I overrode just the PageManager since I don't want to change how pages a > created, just how they are re-used. That's why i differed from > SinglePageManager. Am I doing anything obviously wrong? It's all pretty > simple right now. i started small to try to build the complexity as I > went, > but since nothing I do actually changes the app behavior, I seem stuck. > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/Wicket-back-button-behavior-tp4677587p4677649.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Je n'aime pas seulement ma vie, mais aussi celle des autres. (Blade Runner)
Re: Wicket back button behavior
I am trying to set this up. I looked at some docs and I feel like creating a custom PageManager seems like what I want to do. The thing is, no matter how I implement the getPage(int), the Wicket app behaves the same. The back button still does it's default behavior every time. Here's what I did. I capture the maximum page in touchPage(), and then getPage() returns it. When I hit back during my process flow, initially I get a bunch of calls to getPage() which dutifully returns the currentPage I want. But then, after that, touchPage is called with the prior page (the one the user is going BACK to). What's more, it's called with an ID one GREATER than the maximum page ID as returned in getPage(). getPage() is never called again in that request, and the app then renders the prior page, as if it ignored what getPage() returned. It's like I am missing an additional change setting that would make touchPage() cooperate. I also tried raising a RestartResponseException from within the PageManager when BACK was hit, but that just got me sent to the error page. I overrode just the PageManager since I don't want to change how pages a created, just how they are re-used. That's why i differed from SinglePageManager. Am I doing anything obviously wrong? It's all pretty simple right now. i started small to try to build the complexity as I went, but since nothing I do actually changes the app behavior, I seem stuck. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-back-button-behavior-tp4677587p4677649.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket back button behavior
Hi, The Wicket way would be to roll your own IPageManager or IPageStore or IDiskStore and implement #getPage(int pageId) in a such way so that it always returns the last used page by the user (i.e. session). You may use https://github.com/martin-g/single-page-instance as an inspiration. Otherwise you may also try to do it at the client side, i.e. with JavaScript. Play with History APIs - pushState(), replaceState(), history.forward(), history.go(history.length-1), etc. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Apr 3, 2017 at 3:40 PM, Entropy wrote: > By default wicket does it's serialized back button thing. For most of our > apps, this has been fine. We have a new one where this behavior, showing > the page in a previous state and allowing the user to proceed from there, > is > completely inappropriate. > > Ideally, when a user tries to go back to a previous page version, I'd like > to re-display the current page in it's current state (as if they hit reload > instead). Seems like since Wicket is tracking the page version in the > query > string that should be do-able. > > I found some articles suggesting how to put Wicket into a "stateless" mode > where the page always displays the current/freshest data, but am not > getting > what I expect. > > I tried: > getPageSettings().setVersionPagesByDefault(false); > > But this didn't seem to alter behavior at all. I also tried: > setStatelessHint(true); > > on my pages, and that didn't change any behavior either. Maybe I'm barking > up the wrong tree? How can I get wicket to just re-render the current page > in it's current state if the user tries to use the back button? Basically > just like as if they hit the reload button? > > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/Wicket-back-button-behavior-tp4677587.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Wicket back button behavior
By default wicket does it's serialized back button thing. For most of our apps, this has been fine. We have a new one where this behavior, showing the page in a previous state and allowing the user to proceed from there, is completely inappropriate. Ideally, when a user tries to go back to a previous page version, I'd like to re-display the current page in it's current state (as if they hit reload instead). Seems like since Wicket is tracking the page version in the query string that should be do-able. I found some articles suggesting how to put Wicket into a "stateless" mode where the page always displays the current/freshest data, but am not getting what I expect. I tried: getPageSettings().setVersionPagesByDefault(false); But this didn't seem to alter behavior at all. I also tried: setStatelessHint(true); on my pages, and that didn't change any behavior either. Maybe I'm barking up the wrong tree? How can I get wicket to just re-render the current page in it's current state if the user tries to use the back button? Basically just like as if they hit the reload button? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-back-button-behavior-tp4677587.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org