I will look at that patch but it is weird, it shouldnt be needed that
that is in the page param, because the special
BookmarkabkleInterfaceRequestTarget already does have all the needed
info
On 5/18/08, Doug Donohoe <[EMAIL PROTECTED]> 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-tp17304155p17306650.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
