hi felix, On 7/25/08, 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 LOL nice terminology :-)
> names and applying an algorithm to select a script based on the request URL, > this proposal is somewhat problematic. i know :-) > 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 ok. > - 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... this does not work, since i don't know what they were before (unless i remember them in the request). i think it would be sufficient if i could set a temporary selector that takes precedence from the "real" ones during script resolution of "this" include. in a way that a request...getSelectors() in the included request does still show the ones present outside of the include. > Now, maybe you are not even referring to the include tag (jsp:include) but > to the include directive <[EMAIL PROTECTED]> ? no, but this would be another interesting option... > 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 ... maybe. but i think would imply a lot of invalidation problems. or does jasper remember the 'included' resources and invalidates the classes accordingly ? if yes, that would be cool, of course. regards, toby
