On 7/28/08, David Nuescheler <[EMAIL PROTECTED]> wrote: > On Mon, Jul 28, 2008 at 9:42 AM, Bertrand Delacretaz > <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 25, 2008 at 2:25 PM, Tobias Bocanegra > > <[EMAIL PROTECTED]> wrote: > >> ...i'm looking for a way to include a jsp script from within another but > >> respecting the resource type hierarchy.... > > > > Just to make sure we're all on the same page: including the *source > > code* of a JSP script within another while taking the current request > > in consideration to select the included script is problematic, as JSP > > scripts are compiled in advance, not during request execution. of course. but it could nevertheless respect the resourceTypeHierarchy.
> > So if you do something like > > <sling:include script="foo.jsp"/> > > I guess what you want is the *output* of the script included in the > > current request's output, right? yup. > fully agreed. > > > > As opposed to including foo.jsp's code in the current script, which > > would work in purely interpreted languages like javascript. > > Then, using the resourceType hierarchy to find the script might be > > what you're looking for. > > precisely... thanks for the summary. well, i see use cases for both 'techniques' , the static on-compile-time include (@include) and the dynamic request include (jsp:include). where the former help structure and modularize you scripts, the later additionally servers for dynamically alter the output based on some parameters/attributes of the request/content/setup. in respect to modularization and structuration of a project, the static @include that works with relative paths and respects the resource type hierarchy would be useful as well and would be sufficient for my current needs). the dynamic include is certainly more powerful but also has a drawback of an extra request processing (incl the filter chain) for each include, although this is probably not always needed. imo, i the developer is very aware of the implications of the 2 include versions, it can result it more robust and performant code of the overall application (if not, he's doomed :-) regards, toby
