[
https://issues.apache.org/jira/browse/WICKET-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernard updated WICKET-5810:
----------------------------
Attachment: NullVersionedPanelReplacement2.zip
Thanks Martin for your single-page-instance project and the link to the
discussion. I couldn't find the problems with your solution, so I have perhaps
overlooked something.
I agree with your explanation that setVersioned(false) is specific wrt. the
Page instance. With my provided 2nd test case, I am trying to break out out of
this limitation by creating for a single mapped page class only a single
instance with page ID 0.
Clicking on a link for that page re-uses that single instance if it already
exists. I could check for isVersioned() == false but I don't for the purpose of
this demo.
My implementation plugs in SingleInstancePageProvider via
NoVersionMapper#processBookmarkable(...).
The critical difference in SingleInstancePageProvider vs PageProvider is as
follows:
private final Integer SINGLE_INSTANCE_PAGE_ID = Integer.valueOf(0);
...
private void resolvePageInstance(...){
...
page = getStoredPage(SINGLE_INSTANCE_PAGE_ID);
if (page == null) {
page = getPageSource().newPageInstance(pageClass, pageParameters);
freshCreated = true;
}
...
My thinking is that if this can be done with so little modification, then it
might be worth considering the potential side effects, deal with them and add a
similar solution to the framework so that what quite a few people are asking
for can be provided in a supported way not as a hack.
> 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,
> NullVersionedPanelReplacement2.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)
