[
https://issues.apache.org/jira/browse/SLING-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972511#action_12972511
]
Alexander Klimetschek commented on SLING-1899:
----------------------------------------------
> not a convenience layer for JSP scripting
This is not about "scripting". map()'s purpose was to generate full URLs to
send back in HTTP responses and that's what it does, regardless from where you
call it.
> within a web framework like wicket
Ok, yes, but that's a special case ;-)
> to pass it over to javascript or JSON you have to manually url-decode the
> value returned by the map method, otherwise it may get double URL-encoded
Could you give an example of passing it over to javascript or JSON?
The normal form of a URL is in its encoded form, including relative URL paths,
such as "/some/path%20foo.html". Any client-side javascript would be expected
to properly parse it if it does more then simply placing it in a href for
example.
But I agree that a map() method that does not do url-encoding would make sense.
I would simply add a new one, make the javadocs on the existing ones more
explicit, but _not_ deprecate them, since they do have a purpose. It should not
be moved to yet-another utility class.
> JcrResourceResolver map method is not reverse operation of resolve method
> with special chars in path
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1899
> URL: https://issues.apache.org/jira/browse/SLING-1899
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Resource 2.0.6
> Reporter: Stefan Seifert
> Attachments: 101216_mapresolv_specialchars_fix.patch,
> 101216_mapresolve_specialchars_test.patch
>
>
> according to the javadocs of the ResourceResolver API interface, the map
> method is intended as the reverse operation of the resolve method.
> this is not the case if the path contains special chars like spaces - they
> are url-encoded, although the javadocs of the API does not require this.
> additionally the resolve method does not url-decode the path (which is
> correct in my opinion because the servlet engine already decodes the path).
> the map method should be fixed, so that not url-encoding takes place in it.
> the application is responsible for url-encoding a path if needed, not the
> sling api.
> i've attached a patch which contains a simple unit tests that makes the
> current implementation fail when resolving a path generated with the map
> method: [^101216_mapresolve_specialchars_test.patch]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
