Hi Catalin, Gabriel's original post was about components extending each other using sling:resourceSuperType, not overriding with the search path (i.e. /apps overriding /libs). But this works as well (although it accomplishes something very different).
I'm guessing we need ITs which demonstrate both of these cases. They'll have to be written with ESP and JSP as that's what is available in the IT environment. Regards, Justin On Thu, Jul 24, 2014 at 12:43 PM, Catalin Buzoiu <[email protected]> wrote: > I believe this is not currently possible because of the different extensions. > The same should hold true between JSPs and ESPs, for example. > > Catalin > > Sent from my iPhone > > On Jul 24, 2014, at 6:35 PM, "Carsten Ziegeler" > <[email protected]<mailto:[email protected]>> wrote: > > Hi, > > isn't it the case that if the jsp is in /libs I can override it with a > Sightly script in /apps ? > > Carsten > > > 2014-07-24 18:29 GMT+02:00 Gabriel Walt > <[email protected]<mailto:[email protected]>>: > > 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 > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]<mailto:[email protected]>
