Yes, that's exactly the case. And to explain why using the resource path is not an option for us, the fact is that if we could just duplicate the resources in a new tree then we would just go ahead and change their resource types as well, but with a few millions of those around it's a bit painful to do so. And in general, even the tooling to inspect browse etc etc that has to deal with them would be struggling a bit.
On Fri, Nov 1, 2013 at 11:54 AM, Bertrand Delacretaz <[email protected] > wrote: > Hi, > > On Fri, Nov 1, 2013 at 4:32 PM, Alessandro Bologna > <[email protected]> wrote: > > ....we have *one* resource, > > (meaning one jcr node if it's a jcr backed resource), at /content/home > with > > sling:resourceType H > > > > if a request is for http://www.example.com/home.html, H points to > > /specific/www.example.com/H/html.jsp > > > > if a request is for http://m.example.com/home.html, H points to > > /specific/m.example.com/H/html.jsp > > Ok got it - so our examples are similar, in that we build an > additional search path for scripts based on the current request. > > In my case, that path is computed based on part of the path of the > resource that's been resolved. > > In your case, that path is computed based on a request header. > > So it looks like a service like follows might do the trick: > > /** Instances of this service are taken into account by the servlet > resolver, > * to look for scripts in more places than just the default /apps and > /libs > * for the current request > */ > public interface ScriptSearchPathsProvider { > /** Return a list of paths that are added in front of the search > * path used to resolve scripts. */ > Set<String> getAdditionalScriptSearchPaths(SlingHttpServletRequest > request); > } > > WDYT? > > One issue that comes to mind is handling the rendering servlet's > cache, as with this it won't be a straight resource type to servlet > mapping anymore...but if we agree on the basic needs we can look at > that when needed. > > -Bertrand >
