Hi Martin,
it seemed reasonable to me to let the mapper decide to drop the
parameters. It already has all information at hand, why delay the
decision and put the burden on the PageProvider?
>My reasoning to null-ify in PageProvider is: if there is parsed pageId
and the page cannot loaded from the
>stores then it is expired, so the page parameters are ignored and new
page instance is created. How do
>you decide to drop the parameters in the mapper ?
If there's a pageId, the request parameters are uninteresting for the
page provider, aren't they?
https://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdiff;h=5e1bf8d8169a8d01f041a1d2bf41a8b8fe170dbd
But feel free to revert this, if null-ifying the parameters in
PageProvider helps you in solving the puzzle of these settings.
WICKET-5068 is really important IMHO.
Sven
On 01/09/2014 02:12 PM, Martin Grigorov wrote:
Hi Sven,
What was the reason to move the null-yfing of the parsed PageParameters
from PageProvider to AbstractBookmarkableMapper in
https://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdiff;h=b3982a4beff352cd5e61521490a397a926c13eed
and
https://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdiff;h=5e1bf8d8169a8d01f041a1d2bf41a8b8fe170dbd
I am working on https://issues.apache.org/jira/browse/WICKET-4686 and I had
an issue
with
org.apache.wicket.core.request.mapper.PackageMapperTest#decodeNamedParameters
because of this change. So I reverted it in branch sandbox/WICKET-4686.
My reasoning to null-ify in PageProvider is: if there is parsed pageId and
the page cannot loaded from the stores then it is expired, so the page
parameters are ignored and new page instance is created.
How do you decide to drop the parameters in the mapper ?
Other related tickets that I'd like to address for Wicket 7:
https://issues.apache.org/jira/browse/WICKET-5068
https://issues.apache.org/jira/browse/WICKET-5070
Martin Grigorov
Wicket Training and Consulting
