Hi, Am Montag, den 08.11.2010, 17:40 +0100 schrieb Stefan Seifert: > 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.
Well, the map methods are intended to be the reverse to the resolve methods (and vice versa). As such the namespace mangling is a required part of the operation. If there is a concrete case of wrong URL encoding/externalizing, please report a JIRA issue such that we can fix this. > > besides this, it would be helpful if the namespace mangling code could be > called from outside as well, e.g. JcrResourceUtil class. Well, namespace mangling is a simple application of a regexp search/replace. IMHO we can expose this as a utility method. But what is your use case for that ? Regards Felix
