Hi Alessandro Take a look at SLING-1778 for how an approach using ResourceProviders could look like.
Regards Julian https://issues.apache.org/jira/browse/SLING-1778 On Sat, Nov 2, 2013 at 4:38 PM, Alessandro Bologna <[email protected]> wrote: > 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 >> >> >> >>
