Hi,
Tobias Bocanegra schrieb:
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 :-)
I have to say, that the longer I think of it, the more I don't like the
idea of hacking up the static include directive to respect some resource
type hierarchy. Just off my belly there are two cases, where this might
result in unexpected behaviour:
* If you change the resource super type after the script is compiled
another static script needs to be included, which is not actually
the case unless you remove the JSP file and force recompilation
* If a resource has explicitly "overwritten" the resource super type
the modified super type is not reflected in the compiled JSP
Hence -1 to this request (as requested in Sling-586).
Regards
Felix
