[
https://issues.apache.org/jira/browse/WICKET-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bernard updated WICKET-5810:
----------------------------
Attachment: NullVersionedPanelReplacement.zip
Test case in zip file
> 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. 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)
