Justin, Felix and Bertrand, first of all thank you all for helping out. I think that for now the suggested idea of just wrapping the resource and (kindly) overriding the resource type based on the request will work, but, as Bertrand requested, I'll try to explain my use case.
In my organization, we produce quite a lot of web/digital contents, and these contents are reused in multiple context, such as websites, mobile devices and so on. Often multiple teams, with different release schedules are in charge on these products that, again, share the same content (articles, galleries etc). They just reuse them in new products. While it's reasonable to define a resource type hierarchy and content structure that is common to all the applications, the code is of course different. Actually even the entire application bundle may be using different java components and other code, not just the scripts/jsp/templates. Being able to deploy different application bundles that use same the resource hierarchy differently would allow, at run time, Sling to dispatch a different JSPs and code based on either the http host header (for virtual hosting, say m.mysite.com/content/home.html), or even the resource path (say www.mysite.com/mobile/home.html, in turn resolving to the /content/home.html resource, but using the "mobile" bundle instead of the default one). The sling:resourceType property would be a relative path from /apps/<appname>/, and you could define a virtual host style mapping, with maybe a default application as fallback. I understand that this could be implemented segregating the code in different folders inside the same app and then using selectors and url rewriting rules, but I am afraid that the interdependencies that would be coming out of this approach may be complicating the process unnecessarily. Thanks again! Alessandro On Fri, Nov 1, 2013 at 10:34 AM, Felix Meschberger <[email protected]>wrote: > Hi > > Am 01.11.2013 um 15:32 schrieb Bertrand Delacretaz <[email protected] > >: > > > On Fri, Nov 1, 2013 at 3:26 PM, Felix Meschberger <[email protected]> > wrote: > >> ...I have the impression this sounds like having „configurable“ (or > dynamic) search paths on the ResourceResolver ?... > > > > Yeah, rather dynamic, based on query attributes like Host header etc. > > > > But again, having some concrete use cases for a "minimum viable > > product" implementation would help. > > Yeah, sure. Just throwing around with an idea ;-) > > Regards > Felix >
