What tag exactly do you use to do the include? Because there is an important difference in <cq:include script="foo.jsp" /> compared to <cq/sling:include path="foo" />.
cq:include with script will look up the script by name directly instead of using the resource type/selector/extension resolution (albeit it does handle rt inheritance). Regards, Alex On 01.04.11 10:02, "Marco Dohnke" <marco.doh...@valtech.de> wrote: >Thanks for your answers. Both sound quite interesting. I will check them >although JSPs are not my first choice too. Because I didn't found an >alternative yet, I am also interested in new ideas. > >-----Ursprüngliche Nachricht----- >Von: sam lee [mailto:skyn...@gmail.com] >Gesendet: Freitag, 1. April 2011 15:30 >An: users@sling.apache.org >Betreff: Re: Inheritance and URL decomposition > >I think he really means <cq:include/>. > >/apps/component/page >/apps/component/page/head.jsp >/apps/component/page/body.jsp >/apps/component/page/center.jsp >... >/apps/component/page/html.jsp > >And, in html.jsp, you do: ><cq:include script="center.jsp"/> > > >And, you have: >/apps/component/product @sling:resourceSuperType = component/page >/apps/component/product/center.jsp >/apps/component/product/simple.html.jsp > >And, in simple.html.jsp, you do: ><cq:include script="html.jsp"/> > >Then, I think component/page/html.jsp will be included since you did not >overwrote it in component/product. >And, the html.jsp in turn will include center.jsp.. and since center.jsp >is >overwritten, product/center.jsp will be used. > >But that's CQ stuff. > >In sling, you'll have to write your own taglib that does that. I am not >sure >if <cq:include/> is open source. > >But seriously... I would want to move away from jsp and use a proper html >templating. >Has anyone done this? > > > > >On Fri, Apr 1, 2011 at 9:21 AM, Justin Edelson ><jus...@justinedelson.com>wrote: > >> Depending on the scope of the change between the regular and "simple" >> views, one thing you could do is just have an if statement in your >> center.jsp which does something like this: >> >> <% if ("simple".equals(slingRequest.getSelectorString()) { %> >> <!-- do the simple thing --> >> <% } else { %> >> <!-- do the non-simple thing --> >> <% } %> >> >> Within the if / else blocks, you could include other scripts of course. >> >> HTH, >> Justin >> >> On Fri, Apr 1, 2011 at 5:27 AM, Marco Dohnke <marco.doh...@valtech.de> >> wrote: >> > Yes I know. I also tried several ways with the resourceSuperType. The >> problem is: >> > >> > /apps/myapp/components/product/center.jsp overwrites >> /apps/myapp/components/page/center.jsp because the resourceSuperType is >>set >> on it. >> > >> > But a sling selector is not useable for that. If I use >> /apps/.../product/simple.jsp I have to reimplement all what I >>implemented in >> the page component. That's not very DRY. I thought there is a way to >>achieve >> this. >> > >> > Kind regards, >> > Marco >> > >> > -----Ursprüngliche Nachricht----- >> > Von: Felix Meschberger [mailto:fmesc...@adobe.com] >> > Gesendet: Freitag, 1. April 2011 10:50 >> > An: users@sling.apache.org >> > Betreff: Re: Inheritance and URL decomposition >> > >> > Hi, >> > >> > Am Donnerstag, den 31.03.2011, 14:41 +0100 schrieb sam lee: >> >> Day CQ mailing list is: http://groups.google.com/group/day-communique >> >> >> >> If the resource, /products/my-first-product , has >>sling:resourceType = >> >> /apps/foo/product, >> >> then, to render .html version of the resource, >> /apps/foo/product/html.jsp >> >> will be used. >> >> To render simple.html version of the resource, >> >> /apps/foo/product/simple.html.jsp will be used. >> >> >> >> You can do whatever you want in those .jsp files. >> >> >> >> I am not sure about inheritance. >> >> You can set /products/my-first-product's sling:resourceSuperType = >> >> /apps/foo/page .. >> >> But I am not sure if that will help for your script resolution (using >> >> <sling:include/>). >> > >> > Yes, sling supports sling:resourceSuperType of course and thus all >> > resolutions for scripts and servlets will check the resource type >> > hierarchy. >> > >> > Regards >> > Felix >> > >> > >> > >> > -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
