Hi, taking the given layout
>+ myapp > + A > + A.jsp > + content.jsp > + B > - sling:resourceSuperType = "A" > + B.jsp If I use <sling:include resource="/A" addSelector="content" /> in B.jsp can I use the rendering in content.jsp in B.jsp. I've tried something similar for SLING-475 but it didn't work. Also can I use the flush option as <sling:include flush path="path to resource" respurceType="resource type" /> to remove any earlier loaded content and include new content. and in the replaceSuffix option: can I upload a .txt file and change the extension to .html ex: <sling:include path="path to resource.txt" replaceSuffix=".html" /> janandith. On Fri, Jul 25, 2008 at 7:48 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi Toby, > > Tobias Bocanegra schrieb: > >> hi all, >> i'm looking for a way to include a jsp script from within another but >> respecting the resource type hierarchy. so for example: >> >> + myapp >> + A >> + A.jsp >> + content.jsp >> + B >> - sling:resourceSuperType = "A" >> + B.jsp >> >> and in my B.jsp i want to do something like: >> >> <jsp:include script="content.jsp" /> >> >> this does currently work using selector includes, eg: >> >> <sling:include replaceSelector="content" /> >> >> but this has 2 draw backs: >> - it internally creates a 2nd request (which is actually not wrong, >> but not always needed) >> - it alters the 'selectors' for all subsequent includes (e.g. if the >> content.jsp does another include). >> >> might it be possible to hook into the jsp:include to respect the >> resource search path? >> > > Probably not. > > or maybe adding a new "script" attribute to the sling:include tag ? >> > > Technically the better option. > > >> WDYT ? >> > > Given how Sling resolves scripts by insulating the user from real script > names and applying an algorithm to select a script based on the request URL, > this proposal is somewhat problematic. > > In fact I even would dispute the drawbacks: > - both sling:include and jsp:include are implemented in terms of a > RequestDispatcher. So they both do a "second request" if you wish. Only that > the SlingRequestDispatcher used (in both cases actually) does not really go > through the servlet container but remains within Sling > - yes, "replaceSelector" alters the set of selectors. But this is the name > of the game and how it works. If you would want to continue including > without selectors you just replace them again... > > Now, maybe you are not even referring to the include tag (jsp:include) but > to the include directive <[EMAIL PROTECTED]> ? In this case, I am not sure, > whether > and how we could do something. Maybe we would have to hackup the Jsp > Compiler's handling of this directive ... > > Regards > Felix >
