Gabriel- IMHO, your scenario is invalid and has nothing to do with the difference in scripting engines. If you have my-component/my-component.jsp and my-sub-component has a sling:resourceSuperType of my-component, then the correct way to have a script for my-sub-component is to call that script my-sub-component.<ext> (where ext could be any valid script extension).
To be clear, this is specific to the use of the component name as the script name. If instead, you named these scripts html.<ext>, then the name would be consistent, i.e. my-sub-component/html.html will override my-component/html.jsp. The point you make about sling:call is different. That's an implementation choice of the author of the base component to tie their component to a specific scripting engine. If the author didn't want to do that, they shouldn't use sling:call and instead use sling:include with replaceSelectors. Regards, Justin On Thu, Jul 24, 2014 at 12:29 PM, Gabriel Walt <gw...@adobe.com> wrote: > > Hi all, > > Currently, when components are built with one script language (like JSP), it > is hard or impossible to extend them with another script language (like > Sightly). > > For example, if there is a my-component/my-component.jsp, this cannot be > overridden with a Sightly script in > my-sub-component/my-component.html (my-sub-component having a > sling:resourceSuperType that points to my-component). > > Wouldn't it be interesting to allow Sling overrides to work independently of > the scripting language? > > On a related topic, if a script includes another one, it is also impossible > to override that included file in another scripting language. > > For example, if my-component/my-component.jsp does a <sling:call > script="myscript.jsp"/>, then myscript.jsp cannot be overridden with a > my-sub-component/myscript.html Sightly script. > > This makes the components very specific to the language they have been > implemented in and not generic enough to allow developers to choose their > language of choice when building upon an existing set of foundation > components. > > Would there be a way to improve that and remove that limitation? > > Gabriel > >
