This particular change is relatively simple. I modified the code to take
into account both possible scenarios:
1) wicket:interface passed in via query string
2) wicket:interface passed in via path parameters (as is done for several of
the mount strategies)
Prior to my fix, #1 was not taken into account which caused the bug I'm
seeing.
Essentially what happens now is that if the wicket:interface is not found
already, it then looks in parameters passed in #2 style.
-Doug
Johan Compagner wrote:
>
> i just need to look at it a bit more
> because that wicket:interface parameter cant go into the bookmarkable page
> constructor
> that is just a big no no.. As long as that doesnt happen i dont mind to
> much.
>
> johan
>
>
> On Mon, May 19, 2008 at 3:56 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>
>>
>> The patch fixed the problem I was seeing.
>>
>> I'm not sure how to create a good test case for this. The WicketTester
>> doesn't seem to replicate the behavior of a browser quite properly. The
>> existing test cases could use some improvement because they obviously
>> missed
>> this.
>>
>> It took me about 4 hours to step through the code and learn what was
>> going
>> on. I'm confident it resolves the issue I was seeing and that it retains
>> the old behavior for the case when the wicket interface is passed through
>> the path params.
>>
>>
>> Johan Compagner wrote:
>> >
>> > 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.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Bookmarkable---Stateless-form-submit-bug-%28eelco---need-your-advice%29-tp17304155p17316713.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-tp17304155p17322227.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
