Re: Stateful / versioned / bookmarkable
Hi, First, don't read Bernard's mail. There are too many incorrect statements. On Sun, Oct 27, 2013 at 2:26 PM, Frank Henningsen fr...@henningsen.euwrote: Afaik stateful pages are always versioned. I wonder about these two questions: 1. In this case links to versioned pages are not bookmarkable (since they contain the verion identifier). Correct? This would meen that stateful pages cannot have bookmarkable links. But this contradicts some statements in the wicket documenbtation (e.g. https://cwiki.apache.org/confluence/display/WICKET/Pages). Yes. This is correct. A stateful page is not truly bookmarkable. Wicket uses the httpSessionId+pageId as an identifier to store/load a page. If you give an url with pageId to someone else then there is a (big) chance that (s)he will not see the same as you. This is because (s)he will have new Http Session and Wicket won't be able to find a page with such pageId in his data store. If this was possible then this would be big security issue. Instead Wicket will create a new/fresh instance of this page by using the bookmarkable/mounted url and show it. If you want to show the same data to all user having this url then the state should be in the url itself, e.g. parameters encoded in the path or in the query string. 2. I believe having stateful pages without versioninig are a valid use case (i.e. storing just one page instance per page, e.g. for caching pre calculated values or remembering some GUI settings, the back button leads always to the same stored instance). Are there good reasons to avoid such a scenario? Or are there good practices to achive it? By calling page.setVersioned(false) Wicket will not create new version of the page for every change in its structure/models. When you change the page anyhow Wicket will override its old entry in the disk store with the new one, without increasing the page id. So back button will lead you to the page that linked to the current one, not to a previous state/version of the current page. Thanks, Frank -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Stateful-versioned-bookmarkable-tp4661990.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
Stateful / versioned / bookmarkable
Afaik stateful pages are always versioned. I wonder about these two questions: 1. In this case links to versioned pages are not bookmarkable (since they contain the verion identifier). Correct? This would meen that stateful pages cannot have bookmarkable links. But this contradicts some statements in the wicket documenbtation (e.g. https://cwiki.apache.org/confluence/display/WICKET/Pages). 2. I believe having stateful pages without versioninig are a valid use case (i.e. storing just one page instance per page, e.g. for caching pre calculated values or remembering some GUI settings, the back button leads always to the same stored instance). Are there good reasons to avoid such a scenario? Or are there good practices to achive it? Thanks, Frank -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Stateful-versioned-bookmarkable-tp4661990.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: Stateful / versioned / bookmarkable
Hi, 1) Stateful pages don't need to be versioned: setVersioned(false). But they get a version id in the URL nevertheless, meaning the implementation is not as good as it could be. A stateful page can be bookmarkable. As said above, you get 2 URLs for it, not unique. 2) I agree this has valid use cases, e.g. where the user works with a page that changes state, e.g. via panel replacement, and the user should NOT be able to go back to any of the previous states. Otherwise one cannot implement a reliable state machine if the user can undermine it with back button support. Wicket should support this use case, but AFAIK it does not. We have been able to code various workarounds but there is a problem with these workarounds: They are not stable - Wicket has broken these with subsequent releases - and I have given up playing this cat and mouse game. So until a non-versioned URL coding strategy becomes part of the Wicket core, this will remainin a frustrating up-hill battle. Please note that there will likely not be a 100% perfect solution to this because of the servlet API. On the first page visit, the container adds a jsessionid parameter to the URL until cookie support is established. In that case, there will still be 2 URLs for the same non-versioned page, even without a versioning parameter in the URL. But that is only a minor issue if you can put another page in front of your non-versioned page. Summing it up, I would suggest that you create a Jira issue for Wicket non-versioned URL support for our use cases. A page has to be mountable with such a policy so that as you say, only the latest version is available, and that must be reflected in a stable URL where ony one unique value exists. It can be done, it has been done before, it is just a matter of good will and policy. The Post-Redirect-Get pattern supports this, and I know that other frameworks support this, too. Regards, Bernard On Sun, 27 Oct 2013 05:26:07 -0700 (PDT), you wrote: Afaik stateful pages are always versioned. I wonder about these two questions: 1. In this case links to versioned pages are not bookmarkable (since they contain the verion identifier). Correct? This would meen that stateful pages cannot have bookmarkable links. But this contradicts some statements in the wicket documenbtation (e.g. https://cwiki.apache.org/confluence/display/WICKET/Pages). 2. I believe having stateful pages without versioninig are a valid use case (i.e. storing just one page instance per page, e.g. for caching pre calculated values or remembering some GUI settings, the back button leads always to the same stored instance). Are there good reasons to avoid such a scenario? Or are there good practices to achive it? Thanks, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
