wicket-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Ertl (JIRA)" <j...@apache.org>
Subject [jira] Commented: (WICKET-1428) AutoLinkResolver and Parent-Relative (../) Links
Date Wed, 14 May 2008 15:29:55 GMT

    [ https://issues.apache.org/jira/browse/WICKET-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596791#action_12596791

Peter Ertl commented on WICKET-1428:

I try to summon up what people found out so far and explain my patch using this example:

   resource url = resources/markup.level1.level2.level3.page.TestPage/../../../../base.js

the path splits up into:

  wicket resource prefix = "resources/"
  class anchor for resource = "markup.level1.level2.level3.page.TestPage"
  resource key = "../../../../base.js

the problem is that the browser tries to normalize the resource key by removing the '..' out
of it and shortening the path (but, hey, the resource key is_no_path). as an effect wicket
obviously will not recognize the resource key anymore. using a query parameter 'path=resourceKey'
would work, but this can cause problems with browser caching, default mime type handling,
etc. and also doesn't look quite as pretty (we all know beauty counts in wicket :-)

it's preferrable to have an url that looks like a static resource from the browsers point
of view.

so the patch tried to avoid the '..' at all by using a unambiguous placeholder. I decided

   public static final String PARENT_FOLDER_ESCAPE = "wicket:up";

as Igor suggested in a previous post.

It might be a good idea to make this customizable for example by a setter called


or whatever you would like it to name.

so resource key generation is only mimimally affected by my patch in 

 org.apache.wicket.SharedResources#resourceKey(final String path, final Locale locale, final
String style):

	before :
		final String basePath = Files.basePath(path, extension);

		final String basePath = Files.basePath(path, extension).replace("../", PARENT_FOLDER_ESCAPE
+ "/");

this means any occurences of '../' in the resource key will be replace by 'wicket:up/'

the other place that needs to be changed is the part where the url gets sent to wicket and
the resource key is not defined in Application.getSharedResources() yet. this can for example
happen when the session changes the server node in a cluster. wicket takes the resourceKey
out of the url, looks up the file in the corresponding package and adds it to the application's
shared resources. that's the only place we need a _real_ file system relative path. so we
have to change back the 'wicket:up' to '..' and all is fine.

  SharedResourceRequestTarget#respond(RequestCycle requestCycle)

	String path = resourceKey.substring(ix + 1);
	String path = resourceKey.substring(ix + 1).replace(SharedResources.PARENT_FOLDER_ESCAPE,
the patch will only affect resource url's that go up the path hierarchy and are broken anyway.
so applying it should not be dangerous at all for resource urls in general or change expected
wicket behavior.
would be great if you could put that patch into trunk :-)

> AutoLinkResolver and Parent-Relative (../) Links
> ------------------------------------------------
>                 Key: WICKET-1428
>                 URL: https://issues.apache.org/jira/browse/WICKET-1428
>             Project: Wicket
>          Issue Type: New Feature
>          Components: wicket
>    Affects Versions: 1.3.2
>            Reporter: James Carman
>             Fix For: 1.5-M1
>         Attachments: wicket-1428-use-wicket-up.patch, WICKET-1428.patch, wicket-link-outside-of-package.zip
> Suppose I have a package structure like this:
> com.mycompany.myproject
> --- module1
> ------- page
> --------- Page1.html
> --- module2
> ------- page
> --------- Page2.html
> If I want to autolink from Page1.html to Page2.html, it would look like:
> <wicket:link>
>  <a href="../../module2/page/Page2.html">Click Here!</a>
> </wicket:link>
> This is not working, however.  The AutoLinkResolver spits out a warning message:
> "WARN  - AutoLinkResolver           - Did not find corresponding java class: .....module2.page.Page2"

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

View raw message