I posted a bug and patch
https://issues.apache.org/jira/browse/WICKET-1643
Doug Donohoe wrote:
>
> The BookmarkablePageRequestTargetUrlCodingStrategy needs it so this code
> is run:
>
> return new
> BookmarkableListenerInterfaceRequestTarget(pageMapName,
> (Class)bookmarkablePageClassRef.get(),
> parameters, requestParameters
> .getComponentPath(),
> requestParameters.getInterfaceName(),
> requestParameters.getVersionNumber());
>
> Otherwise my form's onSubmit method is not called because the interface
> isn't recognized.
>
> I've already fixed the code and I'll submit a patch.
>
> -Doug
>
>
> Johan Compagner wrote:
>>
>> i dont get what is the problem at your place
>> At that time the wicket interface should be removed
>> else the page parameters has wicket params in it that shouldnt be those
>> dont
>> belong to user params.
>>
>> but why is this a problem?
>>
>> Why do you need that param later on?
>>
>> johan
>>
>>
>> On Sun, May 18, 2008 at 5:26 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I'm tracking down a bug where a stateless form submission isn't working
>>> if
>>> I
>>> reboot my tomcat server. The issue is that Wicket doesn't recognize the
>>> wicket:interface parameter that is passed down.
>>>
>>> I believe I've tracked down the problem to this code in
>>> BookmarkablePageRequestTargetUrlCodingStrategy:
>>>
>>> // do some extra work for checking whether this is a
>>> normal
>>> request to a
>>> // bookmarkable page, or a request to a stateless page
>>> (in
>>> which case a
>>> // wicket:interface parameter should be available
>>> final String interfaceParameter = (String)parameters
>>>
>>> .remove(WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME);
>>>
>>> if (interfaceParameter != null)
>>> {
>>>
>>> WebRequestCodingStrategy.addInterfaceParameters(interfaceParameter,
>>> requestParameters);
>>> return new
>>> BookmarkableListenerInterfaceRequestTarget(pageMapName,
>>>
>>> (Class)bookmarkablePageClassRef.get(), parameters, requestParameters
>>>
>>> .getComponentPath(),
>>> requestParameters.getInterfaceName(),
>>>
>>> requestParameters.getVersionNumber());
>>> }
>>>
>>>
>>> The issue is that the 'parameters' will never contain the
>>> INTERFACE_PARAMETER_NAME because it would have been removed in
>>> WebRequestCodingStrategy:decode:215 which as far as I can tell is always
>>> called first (from RequestCycle.step.RESOLVE_TARGET:1233).
>>>
>>> The 'requestParameters' should already have the interface parameters, so
>>> it
>>> isn't clear why the addInterfaceParameters() logic is being called again
>>> (it
>>> is already called in WebRequestCodingStrategy:decode:200).
>>>
>>> In what case was this logic necessary? Being new to the code base, I
>>> don't
>>> know every possible code path, so perhaps there is a different way of
>>> getting to this point that I'm not seeing.
>>>
>>> -Doug
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Bookmarkable---Stateless-form-submit-bug-%28eelco---need-your-advice%29-tp17304155p17304155.html
>>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Bookmarkable---Stateless-form-submit-bug-%28eelco---need-your-advice%29-tp17304155p17307258.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
