[
https://issues.apache.org/jira/browse/WICKET-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bernard updated WICKET-4014:
----------------------------
Attachment: ExpiryFallbackParametersQuickStart1.5.zip
I could verify that recovery works with parameters. This is more than what I
could achieve with 1.4. You asked me to test harder. I can break it with the
attached testcase where the GET parameter has the same name as the form field.
I don't know whether this is out of scope.
> Wicket 1.5 Form Post Action and Link Get discard Page Class Information
> -----------------------------------------------------------------------
>
> Key: WICKET-4014
> URL: https://issues.apache.org/jira/browse/WICKET-4014
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5-RC7
> Environment: Wicket version: 1.5-RC7
> java version "1.6.0_25"
> Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
> Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
> Server: GlassFish 3.1.1
> Reporter: bernard
> Assignee: Martin Grigorov
> Fix For: 1.5.1
>
> Attachments: ExpiryFallbackParametersQuickStart1.5.zip,
> ExpiryFallbackQuickStart1.4.zip, ExpiryFallbackQuickStart1.5.zip
>
>
> Page expiry is a very annoying and perplexing event especially if users stay
> logged in via remember-me cookie.
> It is therefore not a fancy enhancement but an essential business requirement
> to not drop the user out of context after session expiry.
> Only stateless pages can fully achieve this, but it is not always desirable
> to go fully stateless, especially while a recovery solution already exists.
> In 1.4, this appears to be automatic with
> BookmarkablePageRequestTargetUrlCodingStrategy - without any additional
> coding.
> The solution is well known - keep as much state in the client as required to
> recover the page class, and possibly even its page parameters, and to not
> destroy this information.
> The two attached testcases show two possible methods of page fallback
> recovery (one with AJAX, one without) that already work behind the scenes.
> Of course it is easy with AJAX, to just force a page reload, but this is not
> discussed here. AJAX just serves to demonstrate how easy the principle
> actually is.
> In most cases the user could successfully reload the page but Wicket 1.5
> can't create a response because it has forgotten the class of the expired
> page.
> In 1.4, it is possible to recover the class of an expired page via its mount
> path.
> This feature is lost in 1.5.
> To get this functionality back in a more streamlined fashion, I am
> additionaly proposing in a separate jira issue 4013 to store page class and
> page parameters in PageExpiredException.
> Meanwhile, the focus of this issue is to request whatever means to not
> overwrite the path of a page in a form post action or get request, and to get
> the page class back as in 1.4 by whatever means.
> The two attached testcases may be helpful for expermintation. The 1.4 tescase
> demonstrates how the scheme works, unfortunately I could not fill the blanks
> in the 1.5 testcase.
> In 1.4,
> a form tag is rendered as:
> <form wicket:id="form"
> action="?wicket:interface=:0:form::IFormSubmitListener::"
> This is requested as:
> /testForm.0?wicket:interface=:0:form::IFormSubmitListener::
> and the page class can be recovered from the mount path "testForm" as in
> mount(new HybridUrlCodingStrategy("testForm", TestPageForm.class));
> an anchor tag is rendered as:
> <a href="?wicket:interface=:0:linkSwitch::ILinkListener::"
> This is requested as:
> /testLink.0?wicket:interface=:0:linkSwitch::ILinkListener::
> and the page class can be recovered from the mount path "test" as in
> mount(new HybridUrlCodingStrategy("testLink", TestPageLink.class));
> In 1.5,
> a form tag is rendered as:
> <form wicket:id="form" action="wicket/page?0-2.IFormSubmitListener-form"
> This is requested requested as:
> /wicket/page?0-1.IFormSubmitListener-form
> This overwrites the mount path "testForm" as in
> mountPage("testForm", TestPageForm.class);
> Consequently the server cannot discover the page class
> an anchor tag is rendered as:
> <a href="wicket/page?0-1.ILinkListener-linkSwitch"
> This is requested requested as:
> /wicket/page?0-1.ILinkListener-linkSwitch
> This overwrites the mount path "testLink" as in
> mountPage("testLink", TestPageLink.class);
> Consequently the server cannot discover the page class
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
