You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Dominik Drzewiecki (JIRA)" <ji...@apache.org> on 2009/01/31 23:57:59 UTC

[jira] Created: (WICKET-2065) Generated urls for mounted pages contain redundant trailing "/"

Generated urls for mounted pages contain redundant trailing "/"
---------------------------------------------------------------

                 Key: WICKET-2065
                 URL: https://issues.apache.org/jira/browse/WICKET-2065
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 1.3.5, 1.3.6, 1.4-RC2
            Reporter: Dominik Drzewiecki


Is it OK (i.e. "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

It looks even more awkward when there are more parameters and part of them is encoded as a query string:
http://localhost:8080/dummy-web/help/content/a/?param2=value2/;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 stumbled upon an issue https://issues.apache.org/jira/browse/WICKET-765. Apart from the compatibility with wicket 1.2 I see no rationale for trailing "/". Looking at implementations of IRequestTargetUrlCodingStrategy I come to the conclusion the the "append("/")" is being overused and redundant especially when it is preceded by the following code which makes sure that the "/" is in place before adding another parameter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (WICKET-2065) Generated urls for mounted pages contain redundant trailing "/"

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-2065.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 1.4-RC2

> Generated urls for mounted pages contain redundant trailing "/"
> ---------------------------------------------------------------
>
>                 Key: WICKET-2065
>                 URL: https://issues.apache.org/jira/browse/WICKET-2065
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.5, 1.3.6, 1.4-RC2
>            Reporter: Dominik Drzewiecki
>            Assignee: Igor Vaynberg
>             Fix For: 1.4-RC2
>
>         Attachments: o.a.w.r.t.coding.patch
>
>
> Is it OK (i.e. "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
> It looks even more awkward when there are more parameters and part of them is encoded as a query string:
> http://localhost:8080/dummy-web/help/content/a/?param2=value2/;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 stumbled upon an issue https://issues.apache.org/jira/browse/WICKET-765. Apart from the compatibility with wicket 1.2 I see no rationale for trailing "/". Looking at implementations of IRequestTargetUrlCodingStrategy I come to the conclusion the the "append("/")" is being overused and redundant especially when it is preceded by the following code which makes sure that the "/" is in place before adding another parameter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WICKET-2065) Generated urls for mounted pages contain redundant trailing "/"

Posted by "Dominik Drzewiecki (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominik Drzewiecki updated WICKET-2065:
---------------------------------------

    Attachment: o.a.w.r.t.coding.patch

Proposed patch makes sure that each parameter before being added to the generated url is precedeeded by "/" rather than being unconditionally appended by  a "/" regardless it is the last one or not. Sorry for several lines of code in the patch changed due to ide formatting diffs. Be warned that several test cases that fail due to the differences in generated output markup are not corrected by this patch. The test cases that fail (and require to update their respective expected output markup):
  testIndexedUrlMountedPageWithComponentThatUsesUrlForResourceListener(org.apache.wicket.request.target.coding.IndexParamWithStatelessIFrameTest)
  testIndexedLink(org.apache.wicket.markup.html.link.IndexedParamUrlCodingTest)
  testStatelessDefaultUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
  testStatefullDefaultUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
  testStatelessIndexedUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
  testStatefullIndexedUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
  testStatelessHybridUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
  testStatefullHybridUrlCodingStrategy(org.apache.wicket.request.target.coding.StatelessStatefullUrlCodingStrategyTest)
  testAppendParametersAppendingStringBufferMap1(org.apache.wicket.request.target.coding.MixedParamUrlCodingStrategyTest)
  testAppendParametersAppendingStringBufferMap2(org.apache.wicket.request.target.coding.MixedParamUrlCodingStrategyTest)
  testAppendParametersAppendingStringBufferMap5(org.apache.wicket.request.target.coding.MixedParamUrlCodingStrategyTest)
  testAppendParametersAppendingStringBufferMap6(org.apache.wicket.request.target.coding.MixedParamUrlCodingStrategyTest)
  testPage(org.apache.wicket.util.parse.metapattern.parsers.IndexedParamTest)
  testStatelessComponentPageWithMount(org.apache.wicket.stateless.StatelessComponentTest)
  testStatelessComponentPageWithParamsWithMount(org.apache.wicket.stateless.StatelessComponentTest)
  testStatelessComponentPageWithParamsWithIndexMount(org.apache.wicket.stateless.StatelessComponentTest)

> Generated urls for mounted pages contain redundant trailing "/"
> ---------------------------------------------------------------
>
>                 Key: WICKET-2065
>                 URL: https://issues.apache.org/jira/browse/WICKET-2065
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.5, 1.3.6, 1.4-RC2
>            Reporter: Dominik Drzewiecki
>         Attachments: o.a.w.r.t.coding.patch
>
>
> Is it OK (i.e. "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
> It looks even more awkward when there are more parameters and part of them is encoded as a query string:
> http://localhost:8080/dummy-web/help/content/a/?param2=value2/;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 stumbled upon an issue https://issues.apache.org/jira/browse/WICKET-765. Apart from the compatibility with wicket 1.2 I see no rationale for trailing "/". Looking at implementations of IRequestTargetUrlCodingStrategy I come to the conclusion the the "append("/")" is being overused and redundant especially when it is preceded by the following code which makes sure that the "/" is in place before adding another parameter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (WICKET-2065) Generated urls for mounted pages contain redundant trailing "/"

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg reassigned WICKET-2065:
-------------------------------------

    Assignee: Igor Vaynberg

> Generated urls for mounted pages contain redundant trailing "/"
> ---------------------------------------------------------------
>
>                 Key: WICKET-2065
>                 URL: https://issues.apache.org/jira/browse/WICKET-2065
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.5, 1.3.6, 1.4-RC2
>            Reporter: Dominik Drzewiecki
>            Assignee: Igor Vaynberg
>         Attachments: o.a.w.r.t.coding.patch
>
>
> Is it OK (i.e. "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
> It looks even more awkward when there are more parameters and part of them is encoded as a query string:
> http://localhost:8080/dummy-web/help/content/a/?param2=value2/;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 stumbled upon an issue https://issues.apache.org/jira/browse/WICKET-765. Apart from the compatibility with wicket 1.2 I see no rationale for trailing "/". Looking at implementations of IRequestTargetUrlCodingStrategy I come to the conclusion the the "append("/")" is being overused and redundant especially when it is preceded by the following code which makes sure that the "/" is in place before adding another parameter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.