[
https://issues.apache.org/jira/browse/WICKET-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bernard updated WICKET-5810:
----------------------------
Description:
This is a follow-up issue from issue WICKET-5693.
I am for now dropping from my requirement the provision of a mapper that does
not show the version number in the URL, for the reason that this seems to
complicate the discussion, not for the reason that I don't need it.
Instead I am focusing on the essential requirement to prevent double submits
which should never happen if a stateful page was truly non-versioned in the
session scope, and the latest page instance cannot process a submit request. We
can discuss the URL issue later.
To keep my use case simple, I am creating a basic implementation of a page
where the user replaces an old panel with a new one. Once this panel is
replaced, the user should not be given the chance to access any page version
containing the old panel.
Only then, IMHO, would the contract of Component#setVersioned(false) be fully
implemented.
When executing the attached test case as a web app, one finds that after panel
replacement with the new panel, it is possible to display the page having the
version containing the old panel by clicking on the original link to the page.
It appears that Wicket just starts fresh and forgets that the current version
of the page contains the new panel not the old one. It creates new version
numbers - however I am not saying that the numbers reflect the number of
versions in the session. I understand that most likely only a single version
exists.
I was surprised to find in the "Apache Wicket Cookbook"
http://www.packtpub.com/apache-wicket-cookbook/book
in recipe0203 a complex method to prevent double submits via the old J2EE
server token pattern. I was thinking that Wicket, supporting server side
component state, actually provides the token via a non-versioned page instance
(singleton per session) out of the box. I hope that it is not be too late to
implement this essential feature by addressing this Jira issue.
I acknowledge that panel replacement may have its own issues, but it is useful
in a testcase, demonstrating component state. One could simply add a server
token to the page instance and process any request depending on it.
was:
This is a follow-up issue from issue WICKET-5693.
I am for now dropping from my requirement the provision of a mapper that does
not show the version number in the URL, for the reason that this seems to
complicate the discussion, not for the reason that I don't need it.
Instead I am focusing on the essential requirement to prevent double submits
which should never happen if a stateful page was truly non-versioned in the
session scope. We can discuss the URL issue later.
To keep my use case simple, I am creating a basic implementation of a page
where the user replaces an old panel with a new one. Once this panel is
replaced, the user should not be given the chance to access any page version
containing the old panel.
Only then, IMHO, would the contract of Component#setVersioned(false) be fully
implemented.
When executing the attached test case as a web app, one finds that after panel
replacement with the new panel, it is possible to display the page having the
version containing the old panel by clicking on the original link to the page.
It appears that Wicket just starts fresh and forgets that the current version
of the page contains the new panel not the old one. It creates new version
numbers - however I am not saying that the numbers reflect the number of
versions in the session. I understand that most likely only a single version
exists.
I was surprised to find in the "Apache Wicket Cookbook"
http://www.packtpub.com/apache-wicket-cookbook/book
in recipe0203 a complex method to prevent double submits via the old J2EE
server token pattern. I was thinking that Wicket, supporting server side
component state, actually provides the token via a non-versioned page instance
(singleton per session) out of the box. I hope that it is not be too late to
implement this essential feature by addressing this Jira issue.
I acknowledge that panel replacement may have its own issues, but it is useful
in a testcase, demonstrating component state. One could simply add a server
token to the page instance and process any request depending on it.
> Component#setVersioned(false) should force singleton component instance per
> session
> -----------------------------------------------------------------------------------
>
> Key: WICKET-5810
> URL: https://issues.apache.org/jira/browse/WICKET-5810
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 6.16.0
> Environment: N/A
> Reporter: bernard
> Attachments: NullVersionedPanelReplacement.zip
>
>
> This is a follow-up issue from issue WICKET-5693.
> I am for now dropping from my requirement the provision of a mapper that does
> not show the version number in the URL, for the reason that this seems to
> complicate the discussion, not for the reason that I don't need it.
> Instead I am focusing on the essential requirement to prevent double submits
> which should never happen if a stateful page was truly non-versioned in the
> session scope, and the latest page instance cannot process a submit request.
> We can discuss the URL issue later.
> To keep my use case simple, I am creating a basic implementation of a page
> where the user replaces an old panel with a new one. Once this panel is
> replaced, the user should not be given the chance to access any page version
> containing the old panel.
> Only then, IMHO, would the contract of Component#setVersioned(false) be fully
> implemented.
> When executing the attached test case as a web app, one finds that after
> panel replacement with the new panel, it is possible to display the page
> having the version containing the old panel by clicking on the original link
> to the page.
> It appears that Wicket just starts fresh and forgets that the current version
> of the page contains the new panel not the old one. It creates new version
> numbers - however I am not saying that the numbers reflect the number of
> versions in the session. I understand that most likely only a single version
> exists.
> I was surprised to find in the "Apache Wicket Cookbook"
> http://www.packtpub.com/apache-wicket-cookbook/book
> in recipe0203 a complex method to prevent double submits via the old J2EE
> server token pattern. I was thinking that Wicket, supporting server side
> component state, actually provides the token via a non-versioned page
> instance (singleton per session) out of the box. I hope that it is not be too
> late to implement this essential feature by addressing this Jira issue.
> I acknowledge that panel replacement may have its own issues, but it is
> useful in a testcase, demonstrating component state. One could simply add a
> server token to the page instance and process any request depending on it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
