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.
OTOH if it is really automatic and applies to all resources (or the few exceptions are trivial and based on existing flags on the original sources) I agree, creating a separate tree might be difficult. In that case I could imagine having a custom resource provider (I am not sure if that was proposed already?) might be useful: say you hook it under /alternative2 and just wrap the JCR resources from /some/foo, but changing the resource type. And the host header would be used upfront in the webserver or sling mappings to get from Host: myserver to /alternative2. I would be careful with too much dynamic script or resource resolution based on headers etc., since this becomes less transparent and is harder to debug. Cheers, Alex 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 >>
