It seems that the fix is as easy as applying the following patch.
Index:
src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java
===================================================================
---
src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java
(revision
739413)
+++
src/main/java/org/apache/wicket/request/target/coding/AbstractRequestTargetUrlCodingStrategy.java
(working
copy)
@@ -117,7 +119,7 @@
{
url.append("/");
}
-
url.append(key).append("/").append(escapedValue).append("/");
+ url.append(key).append("/").append(escapedValue);
}
}
Applying this however results in several test failures:
Failed tests:
testStatelessDefaultUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
testStatefullDefaultUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
testStatelessHybridUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
testStatefullHybridUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
testStatelessComponentPageWithMount(org.apache.wicket.stateless.StatelessComponentTest)
testStatelessComponentPageWithParamsWithMount(org.apache.wicket.stateless.StatelessComponentTest)
But in fact those tests should pass.
For the first 4, the generated markup is semantically identical (but
it's textual representation differs) to the expected one.
The last 2 tests fail, but removing trailing slashes from the
generated urls in the expected markup does the trick.
regz,
/dd
/dd
2009/1/30 Igor Vaynberg <[email protected]>:
> can you open a jira issue please...feel free to attach any tests you have.
>
> -igor
>
> On Fri, Jan 30, 2009 at 12:33 PM, Dominik Drzewiecki
> <[email protected]> wrote:
>> Yep, the problem persists for the wicket built from trunk.
>>
>> /dd
>>
>> 2009/1/30 Igor Vaynberg <[email protected]>:
>>> what wicket version are you using and have you tried with latest from svn?
>>>
>>> -igor
>>>
>>> On Fri, Jan 30, 2009 at 6:49 AM, <[email protected]> wrote:
>>>> Is it OK (ie "by design" as opposed to "by mistake") that the urls
>>>> generated
>>>> for the mounted pages end up with the "/"?
>>>>
>>>> Provided that there's a page that expects single parameter (here:
>>>> "content")...
>>>> public class HelpPage extends WebPage {
>>>> public HelpPage(PageParameters p) {
>>>> super(p);
>>>> add(new DynamicContentPanel("contentPanel", new
>>>> Model<String>(p.getString("content"))));
>>>> }
>>>> }
>>>>
>>>> ...and it is mounted in the Application#init()
>>>> mount(new BookmarkablePageRequestTargetUrlCodingStrategy("help",
>>>> HelpPage.class, null));
>>>>
>>>> ...and further referred to somewhere else as:
>>>> add(new BookmarkablePageLink("helpPage", HelpPage.class, new
>>>> PageParameters("content=a")));
>>>>
>>>> the url in the generated markup is in the following form:
>>>> http://localhost:8080/dummy-web/help/content/a/;jsessionid=11624C6125F8DF4867E3218676D79A29
>>>>
>>>> While IMHO it should read:
>>>> http://localhost:8080/dummy-web/help/content/a;jsessionid=11624C6125F8DF4867E3218676D79A29
>>>>
>>>> The page parameter for both cases is resolved correctly by the HelpPage's
>>>> constructor, so it seems that even though there's an extra "/" at the end
>>>> of
>>>> the url it gets omitted.
>>>> Then why bother generating it?
>>>>
>>>> I looked up in the sources and found that it is the
>>>> AbstractRequestTargetUrlCodingStrategy#appendValue(AppendingStringBuffer
>>>> url, String key, String value) that is responsible for adding an extra
>>>> trailing "/" at the end of the generated url
>>>> It is invoked in the loop, and possibly there's no corner case implemented
>>>> for the last parameter to be encoded.
>>>>
>>>> /regz,
>>>> Dominik Drzewiecki
>>>>
>>>
>>
>
