You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Tobias Bocanegra <to...@day.com> on 2008/07/25 14:25:55 UTC
script include
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?
or maybe adding a new "script" attribute to the sling:include tag ?
WDYT ?
regards, toby
Re: script include
Posted by Tobias Bocanegra <to...@day.com>.
On 7/25/08, janandith jayawardena <ja...@gmail.com> wrote:
> 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.
yes, but with the "path" attribute and not the "resource" attribute
> 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.
>
no. flush means something completely different. if flushes the jsp
writer before executing the include.
>
> 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" />
hmm...iirc, in this case the 'html' scripts are used instead of the
.txt scripts.
>
>
>
>
>
>
> On Fri, Jul 25, 2008 at 7:48 PM, Felix Meschberger <fm...@gmail.com>
> 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 <%@include%> ? 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
> >
>
Re: script include
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Janandith,
Just adding what has not been answered by Tobias.
janandith jayawardena schrieb:
> Hi,
>
> taking the given layout
>
>> + myapp
>> + A
>> + A.jsp
>> + content.jsp
>> + B
>> - sling:resourceSuperType = "A"
>> + B.jsp
>
>
>...
> 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" />
No, the request extension cannot (currently) be modified in an include.
I think the background of this is, that the request extension is tied
somewhat to the content type of the response, which may not be changed
from within an included request.
Regards
Felix
Re: script include
Posted by janandith jayawardena <ja...@gmail.com>.
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 <fm...@gmail.com>
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 <%@include%> ? 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
>
Re: script include
Posted by Tobias Bocanegra <to...@day.com>.
On 7/28/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Bertrand Delacretaz schrieb:
>
> > On Fri, Jul 25, 2008 at 10:10 PM, Tobias Bocanegra
> > <to...@day.com> wrote:
> >
> >
> > > ...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...
> > >
> >
> > I agree with Felix that this could be confusing, but how about
> >
> > <sling:include scriptSelector="content"/>
> >
> > Which, as you suggest, would replace the selectors only for the script
> > resolution of this particular include.
> >
> > Naming this "scriptSelector" would remove the possible confusion with
> > "selector".
> >
>
> So, this selector would just be used for _selecting_ the script, but
> RequestPathInfo.getSelectors() would still return the actual selectors ?
> Sounds interesting.
yes, that would be great.
> But then the actual selectors used for the script selection would not be
> visible. Is this a problem ?
in the most cases probably not :-)
> > > > ... Now, maybe you are not even referring to the include tag
> (jsp:include) but
> > > > to the include directive <%@include%> ?
> > > >
> > > no, but this would be another interesting option....
> > >
> >
> > IIUC the include directive works at script compilation time, so it
> > could not use the current request values, unless we somewhat mangle
> > them into the name of the included script.
> >
>
> Agreed. Thanks for clarifying. So lets drop the idea of hacking up the
> include directive.
i would like to have both, actually. in the most cases, the static
include is very sufficient. and this would also solve the "selector"
problem, since it's completely request independent.
regards, toby
Re: script include
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Fri, Jul 25, 2008 at 10:10 PM, Tobias Bocanegra
> <to...@day.com> wrote:
>
>> ...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...
>
> I agree with Felix that this could be confusing, but how about
>
> <sling:include scriptSelector="content"/>
>
> Which, as you suggest, would replace the selectors only for the script
> resolution of this particular include.
>
> Naming this "scriptSelector" would remove the possible confusion with
> "selector".
So, this selector would just be used for _selecting_ the script, but
RequestPathInfo.getSelectors() would still return the actual selectors ?
Sounds interesting.
But then the actual selectors used for the script selection would not be
visible. Is this a problem ?
>
>>> ... Now, maybe you are not even referring to the include tag (jsp:include) but
>>> to the include directive <%@include%> ?
>> no, but this would be another interesting option....
>
> IIUC the include directive works at script compilation time, so it
> could not use the current request values, unless we somewhat mangle
> them into the name of the included script.
Agreed. Thanks for clarifying. So lets drop the idea of hacking up the
include directive.
Regards
Felix
Re: script include
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jul 25, 2008 at 10:10 PM, Tobias Bocanegra
<to...@day.com> wrote:
> ...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...
I agree with Felix that this could be confusing, but how about
<sling:include scriptSelector="content"/>
Which, as you suggest, would replace the selectors only for the script
resolution of this particular include.
Naming this "scriptSelector" would remove the possible confusion with
"selector".
>> ... Now, maybe you are not even referring to the include tag (jsp:include) but
>> to the include directive <%@include%> ?
> no, but this would be another interesting option....
IIUC the include directive works at script compilation time, so it
could not use the current request values, unless we somewhat mangle
them into the name of the included script.
-Bertrand
Re: script include
Posted by Tobias Bocanegra <to...@day.com>.
On 7/28/08, Felix Meschberger <fm...@gmail.com> wrote:
> You are welcome to JIRA this ;-)
https://issues.apache.org/jira/browse/SLING-585
https://issues.apache.org/jira/browse/SLING-586
regards, toby
Re: script include
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Tobias Bocanegra schrieb:
> ...
>> - 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.
This of course could technically be possible in that we for example we
add tags to specify selector addition/replacement just for a single
include and revert back to the previous ones for further includes....
I am a bit weary of such a feature, though, because it might lead to
hard-to-trace issues. But given some logging (most notably
RequestProgressTracker) this might somewhat be releived.
You are welcome to JIRA this ;-)
>
>> Now, maybe you are not even referring to the include tag (jsp:include) but
>> to the include directive <%@include%> ?
> 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.
Looking at the Jasper Code, it seems that these includes are used to
verify the requirement for recompilation.
We should probably not follow up on this for now .... ;-)
Regards
Felix
Re: script include
Posted by Tobias Bocanegra <to...@day.com>.
hi felix,
On 7/25/08, Felix Meschberger <fm...@gmail.com> 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 <%@include%> ?
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
Re: script include
Posted by Felix Meschberger <fm...@gmail.com>.
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 <%@include%> ? 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
Re: script include
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Tobias Bocanegra schrieb:
> On 7/28/08, David Nuescheler <da...@day.com> wrote:
>> On Mon, Jul 28, 2008 at 9:42 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> > On Fri, Jul 25, 2008 at 2:25 PM, Tobias Bocanegra
>> > <to...@day.com> 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
Re: script include
Posted by Tobias Bocanegra <to...@day.com>.
On 7/28/08, David Nuescheler <da...@day.com> wrote:
> On Mon, Jul 28, 2008 at 9:42 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Fri, Jul 25, 2008 at 2:25 PM, Tobias Bocanegra
> > <to...@day.com> 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
Re: script include
Posted by David Nuescheler <da...@day.com>.
On Mon, Jul 28, 2008 at 9:42 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Fri, Jul 25, 2008 at 2:25 PM, Tobias Bocanegra
> <to...@day.com> 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.
>
> 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?
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.
regards,
david
Re: script include
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jul 25, 2008 at 2:25 PM, Tobias Bocanegra
<to...@day.com> 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.
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?
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.
-Bertrand