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
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 "test" 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
