On 08.11.10 17:40, "Stefan Seifert" <[email protected]> wrote:
> >we're a bit unhappy with the current implementation of the map method in >JcrResourceResolver. > >the SLING api documentation describes it with a clear purpose: it maps a >given resource path to its mapped counterpart, taking mapping defined at >/etc/map or vanity urls into account. the variant with request as first >parameter will add context path and scheme/hostname if possible. > >but besides this functionality it does additional things: > >* the namespace mangling, e.g. replacing /jcr: with /_jcr_ > >* encodes the URL like URLEncoder.encode does > (this is an sideeffect of using the URI.toString() method and not the >URI.getURI() method) > >especially the last one is error-prone, because it has effect only on >urls with special chars in it, which may break code only in certain >circumstances that does not expect the encoding. > >it would be helpful if these two concerns could be separated: > >* remapping a sling resource path > >* externalizing the path, e.g. namespace mangling, encoding the URL > >the latter should be removed from the map method implementation, because >it is not documented in the sling api. or the api documentation should be >updated and perhaps a new map method variant can be defined which maps >but does not externalized the path. > >besides this, it would be helpful if the namespace mangling code could be >called from outside as well, e.g. JcrResourceUtil class. I think you mean the map(String) method in particular? There is also the one where a request object is passed, for having relative links in case the current request fits. All this only applies if you have a /etc/map configuration that includes hostnames, which then might end up in what is returned from the map() methods. Hence both methods are designed to return URIs (absolute or relative), hence the externalization, namespace mangling and URL encoding. To parse it back into its pieces, one has to act like in request processing and use e.g. the java URI class for that. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
