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
