Thanks Alex for the suggestion. No, creating a custom resource provider wasn't suggested, just to decorate the resource. I guess that's another option, short of what was discussed before (the script resolution being augmented with extra paths depending on matched host header).
But now I am curious to know, when instead you say: Those separate resource trees I mentioned could just point to the original > resources, so they don't need to duplicate them. Maybe the trees and/or the > selection of what gets used might look different than the original, so that > can be the only option. > I am confused on how that could be implemented? How do you point a resource tree to another, and make the contents of the tree the same minus the resource type? I mean, that would be cool... I don't think the solution is shared nodes though... Alessandro > On 01.11.2013, at 09:01, Alessandro Bologna <[email protected]> > wrote: > > > 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 > >> > >
