Hi Bertrand, I had a chance to look at that model yesterday and absolutely think this is a great way since it is not too far away from what we have right now and what could be seen as best practice for compositing and customizing applications based on Sling and other propietary "modules".
I think visualizing your blog example with some boxes and lines would help others that yet had not a chance to discuss this to understand how this could work out. What is a bit hard to read from that model is what kind of changes would need to be done in Sling to make that work (just the high level changes not the implementation detail). The detail about the constraint to just use an assembly would therefore be a constraint on the resourceType Path that would be evaluated by the resourceResolver and ignores resourceType not being part of the assembly. The mapping to functionality/resourceTypes out of the underlying modules would be realized through those mappin resources with the resourceSuperType (which then "could" point out of the assembly). I hope my addition helps a bit to clarify the base idea of the assembly pattern and does not create more confusion. Best regards, Dominik On Tue, Jan 27, 2015 at 6:55 PM, Bertrand Delacretaz <bdelacre...@apache.org > wrote: > Hi, > > I've been thinking a lot about a content model that would help Sling > applications be naturally friendly to multi-tenancy and to continuous > deployment where multiple versions of modules need to coexist. > > I have now written those thoughts down at > > https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model > > Feedback is welcome but please keep in mind that this is mostly just > thinking outloud at this point. > > Credit goes to Dominik Suess for the assemblies idea, it looks like > this intermediate routing layer might help make sense of complex > multi-T and multi-M systems. > > -Bertrand >
