Hi IMHO <sling:call> solves a specific problem but at the end of the day is a Sling Anti-Pattern. I am not very happy to evolve this beyond the basic functionality.
The Sling-correct way to render stuff is to use <sling:include> (or <sling:forward> if you will). As such I agree with Carsten to suggest converting the code to use <sling:include>. In fact, the <sling:include> allows you to set a resource type along with the resource (relative) path which may create a virtual resource with the given resource type if the named resource does not exist and thus then execute the respective rendering Regards Felix Am 22.08.2014 um 10:50 schrieb Gabriel Walt <[email protected]>: > > Thanks for your answers! Let me try to provide more context and be more > specific. > > With sling:resourceSuperType (or with /apps /libs overlaying), you can > customize any script of your component. A common practice is to split > large script templates into partials that can then each be independently > customized, to avoid full script duplication, and to adapt only parts > of it. > > The typical example is a page component that can for instance end up with > a structure like: > - page.jsp > - head.jsp > - headlibs.jsp > - body.jsp > - top.jsp > - content.jsp > - bottom.jsp > - bodylibs.jsp > > These scripts are usually all included with something like a sling:call, > but then this makes it impossible in an extending component to use a > different script language than the one used in the super-type (so in our > example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc). > > Thus, it would be nice to be able to do an include of script partials that > are not binding to a particular script language, like for instance: > <sling:call script="myscript.*" /> > instead of: > <sling:call script="myscript.jsp" /> > > Best, > Gabriel > >
