You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Bernard (JIRA)" <ji...@apache.org> on 2015/01/14 02:43:37 UTC

[jira] [Comment Edited] (WICKET-5810) Component#setVersioned(false) should force singleton component instance per session

    [ https://issues.apache.org/jira/browse/WICKET-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14276304#comment-14276304 ] 

Bernard edited comment on WICKET-5810 at 1/14/15 1:43 AM:
----------------------------------------------------------

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 (please check out the attachment), 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.






was (Author: bht):
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)