Dynamically alter script resolution path

[achim <a....@cassini.de>]

Hi,

i am wondering, if can i dynamically alter the script resolution path on a
per-request base?

In CQ3-4 we could dynamically alter the path via the <cq:setpath> tag. We
used this to completely alter the rendition of the website depending of
external factors.

Examples uses for that are

    Using common pages for different tenants in different layouts without
having to copy the page to each tenant.
    Using the exact same content tree for a mobile rendition.


Basically it worked like this: We had N different paths in /apps. One for
each tenant or client:

/apps/default
/apps/tenant1
/apps/tenant2
/apps/tenantN
/apps/tenant1-mobile

But we had only one "real" content-path. All other tenants where virtually
set up by symlinks (i guess i will find a way to fake the symlink-part with
prefixes, that would be removed by rewriting):

/content/common/...
/content/tenant1 -> /content/common
...

Each requests was then marked with a dedicated attribute "tenant", which was
derived by the tenant-prefix, or a header set by the dispatcher.

In the first JSP called, we set the script-path dynamically like this:

<cq:setpath name=&quot;/apps/&lt;% tenant %>"/>
<cq:setpath name="/apps/default"/>

Thus when a request was recognized as belonging to "tenant1-mobile" we would
first look into "/apps/tenant1-mobile" for scripts. If none was found we
would fallback to the default implementation - or to "/libs" if the script
was provided by CQ.

Is there a similar solution in CQ5 to alter the script-searchpath
dynamically. I know that the official CQ5-way would be a different one. I
already evaluated two ways but they do not make me happy:

1. Use the MSM to duplicate the content while changing the resource-types to
a different version.

Drawbacks:
a) We already have a huge amount of content. Duplicating the content would
result in performance issues in retrieving content from the CRX due to cache
eviction and disk-latency but also would slow down the backup-process.
b) I am not a big fan of content being copied asynchronously. I have the
experience, that that sometimes does not work as expected and failures are
hard to track-down and recover from. And again - copying also creates
unnecessary load on the server.

2. Use different selectors for each tenant or view.

Drawbacks:
a) We would cumulate rendering - code for different tenants within the
components resulting in unmaintainable code. We would mix up code for
different tenants in one source-branch, thus being not able to deploy
separately anymore.
b) The URLs are "tainted" and hard to maintain during rendering. If a page
is called with lets say a "mobile" selector we have to ensure, that every
link rendered on that page would also have "mobile" selector.

Any hints or clues how to do that with the CQ- or Sling-API? I am currently
using CQ5.4 (Sling 2?, so any hint should respect, that we are not planning
to hack and exchange Sling which would have uncontrollable side-effects to
the existing system.)

Regards  Achim





--
View this message in context: http://apache-sling.73963.n3.nabble.com/Dynamically-alter-script-resolution-path-tp4021407.html
Sent from the Sling - Users mailing list archive at Nabble.com.