You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Stefan Seifert <ss...@pro-vision.de> on 2009/03/31 01:56:07 UTC
include parameters in sling:include/SlingRequestDispatcher
i think a possibility to pass additional parameters to sling components included by sling:include or SlingRequestDispatcher would be helpful.
example:
<sling:include path="content" resourceType="/apps/xxx/parsys">
<sling:parameter name="allowedComponents" value="/apps/xxx/component1,/apps/xxx/component2,/apps/xxx/component3"/>
<sling:parameter name="css-class" value="section"/>
<sling:parameter name="custom-object" value="<%=referenceToACustomObject%>"/>
</sling:include>
internally, the parameters could be collected in the RequestDispatcherOptions instance, and passed via request attribute to the including component. a convenience class or new methods in an existing interface like SlingHttpServletRequest can provide access to a map of "IncludeParameters".
of course, an application can do this already today by setting request parameters manually to pass them to the component. but this has a drawback: the application has to ensure to clean up the request parameters after the component was rendered. and there is no defined "contract" how to pass include parameters to a component.
one could argue that sling components should only "parameterized" using existing sling capabilities like selectors and extensions, perhaps suffixes. but these capabilities are somewhat limited when passing complex parameter values or even object references as shown in the example above.
WDYT?
stefan
Re: include parameters in sling:include/SlingRequestDispatcher
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Stefan,
Thanks alot for providing the patch. Will look into it as soon as
possible (I already have three or four other patches on my table to also
apply ....)
Regards
Felix
Stefan Seifert schrieb:
> i've submitted a patch that implements such a support and takes your comments into account, using the same semantics as the jsp specification defines:
> https://issues.apache.org/jira/browse/SLING-982
>
> from my initial proposal i dropped the support for passing object references to included requests, but that is a rather exoctic feature anyway.
>
> stefan
>
>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> Sent: Tuesday, March 31, 2009 8:48 AM
>> To: sling-dev@incubator.apache.org
>> Subject: Re: include parameters in sling:include/SlingRequestDispatcher
>>
>> Hi Stefan,
>>
>> Stefan Seifert schrieb:
>>> i think a possibility to pass additional parameters to sling components
>> included by sling:include or SlingRequestDispatcher would be helpful.
>>> example:
>>>
>>> <sling:include path="content" resourceType="/apps/xxx/parsys">
>>> <sling:parameter name="allowedComponents"
>> value="/apps/xxx/component1,/apps/xxx/component2,/apps/xxx/component3"/>
>>> <sling:parameter name="css-class" value="section"/>
>>> <sling:parameter name="custom-object"
>> value="<%=referenceToACustomObject%>"/>
>>> </sling:include>
>>>
>>> internally, the parameters could be collected in the
>> RequestDispatcherOptions instance, and passed via request attribute to the
>> including component. a convenience class or new methods in an existing
>> interface like SlingHttpServletRequest can provide access to a map of
>> "IncludeParameters".
>>> of course, an application can do this already today by setting request
>> parameters manually to pass them to the component. but this has a drawback:
>> the application has to ensure to clean up the request parameters after the
>> component was rendered. and there is no defined "contract" how to pass
>> include parameters to a component.
>>> one could argue that sling components should only "parameterized" using
>> existing sling capabilities like selectors and extensions, perhaps
>> suffixes. but these capabilities are somewhat limited when passing complex
>> parameter values or even object references as shown in the example above.
>>> WDYT?
>> I think adding support for parameters makes perfect sense.
>>
>> But IMHO this should be inline with normal request parameters, that is
>> parameters provided through the <parameter> tag should be accessible
>> through get getParameter* methods of the request object. This makes the
>> parameter thing completely transparent.
>>
>> The drawback of this is in fact, that we would have to clean up after an
>> included, but this may be optimized.
>>
>> On the other, we don't yet support parameters given as part of the
>> include path attribute ... This needs to be implemented...
>>
>> In fact turning to the Servlet 2.5 Spec, there is Section 8.1.1, Query
>> Strings in Request Dispatcher Paths, stating the request to support
>> query parameters. Also the JSP 2.1 spec in Section 5.6, <jsp:param>,
>> states that parameters follow the mechanism of Servlet Spec Section 8.1.1
>>
>> So I think, Sling *must* support query parameters and a <sling:param>
>> tag would have to abide by the rules of the <jsp:param> tag (we might
>> even want to investigate, whether reusing <jsp:param> itself instead of
>> inventing our own makes more sense).
>>
>> Patches welcome ;-)
>>
>> Regards
>> Felix
>>
>>
>>
>>> stefan
>>>
>>>
>
RE: include parameters in sling:include/SlingRequestDispatcher
Posted by Stefan Seifert <ss...@pro-vision.de>.
i've submitted a patch that implements such a support and takes your comments into account, using the same semantics as the jsp specification defines:
https://issues.apache.org/jira/browse/SLING-982
from my initial proposal i dropped the support for passing object references to included requests, but that is a rather exoctic feature anyway.
stefan
>-----Original Message-----
>From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>Sent: Tuesday, March 31, 2009 8:48 AM
>To: sling-dev@incubator.apache.org
>Subject: Re: include parameters in sling:include/SlingRequestDispatcher
>
>Hi Stefan,
>
>Stefan Seifert schrieb:
>> i think a possibility to pass additional parameters to sling components
>included by sling:include or SlingRequestDispatcher would be helpful.
>>
>> example:
>>
>> <sling:include path="content" resourceType="/apps/xxx/parsys">
>> <sling:parameter name="allowedComponents"
>value="/apps/xxx/component1,/apps/xxx/component2,/apps/xxx/component3"/>
>> <sling:parameter name="css-class" value="section"/>
>> <sling:parameter name="custom-object"
>value="<%=referenceToACustomObject%>"/>
>> </sling:include>
>>
>> internally, the parameters could be collected in the
>RequestDispatcherOptions instance, and passed via request attribute to the
>including component. a convenience class or new methods in an existing
>interface like SlingHttpServletRequest can provide access to a map of
>"IncludeParameters".
>>
>> of course, an application can do this already today by setting request
>parameters manually to pass them to the component. but this has a drawback:
>the application has to ensure to clean up the request parameters after the
>component was rendered. and there is no defined "contract" how to pass
>include parameters to a component.
>>
>> one could argue that sling components should only "parameterized" using
>existing sling capabilities like selectors and extensions, perhaps
>suffixes. but these capabilities are somewhat limited when passing complex
>parameter values or even object references as shown in the example above.
>>
>> WDYT?
>
>I think adding support for parameters makes perfect sense.
>
>But IMHO this should be inline with normal request parameters, that is
>parameters provided through the <parameter> tag should be accessible
>through get getParameter* methods of the request object. This makes the
>parameter thing completely transparent.
>
>The drawback of this is in fact, that we would have to clean up after an
>included, but this may be optimized.
>
>On the other, we don't yet support parameters given as part of the
>include path attribute ... This needs to be implemented...
>
>In fact turning to the Servlet 2.5 Spec, there is Section 8.1.1, Query
>Strings in Request Dispatcher Paths, stating the request to support
>query parameters. Also the JSP 2.1 spec in Section 5.6, <jsp:param>,
>states that parameters follow the mechanism of Servlet Spec Section 8.1.1
>
>So I think, Sling *must* support query parameters and a <sling:param>
>tag would have to abide by the rules of the <jsp:param> tag (we might
>even want to investigate, whether reusing <jsp:param> itself instead of
>inventing our own makes more sense).
>
>Patches welcome ;-)
>
>Regards
>Felix
>
>
>
>>
>> stefan
>>
>>
Re: include parameters in sling:include/SlingRequestDispatcher
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Stefan,
Stefan Seifert schrieb:
> i think a possibility to pass additional parameters to sling components included by sling:include or SlingRequestDispatcher would be helpful.
>
> example:
>
> <sling:include path="content" resourceType="/apps/xxx/parsys">
> <sling:parameter name="allowedComponents" value="/apps/xxx/component1,/apps/xxx/component2,/apps/xxx/component3"/>
> <sling:parameter name="css-class" value="section"/>
> <sling:parameter name="custom-object" value="<%=referenceToACustomObject%>"/>
> </sling:include>
>
> internally, the parameters could be collected in the RequestDispatcherOptions instance, and passed via request attribute to the including component. a convenience class or new methods in an existing interface like SlingHttpServletRequest can provide access to a map of "IncludeParameters".
>
> of course, an application can do this already today by setting request parameters manually to pass them to the component. but this has a drawback: the application has to ensure to clean up the request parameters after the component was rendered. and there is no defined "contract" how to pass include parameters to a component.
>
> one could argue that sling components should only "parameterized" using existing sling capabilities like selectors and extensions, perhaps suffixes. but these capabilities are somewhat limited when passing complex parameter values or even object references as shown in the example above.
>
> WDYT?
I think adding support for parameters makes perfect sense.
But IMHO this should be inline with normal request parameters, that is
parameters provided through the <parameter> tag should be accessible
through get getParameter* methods of the request object. This makes the
parameter thing completely transparent.
The drawback of this is in fact, that we would have to clean up after an
included, but this may be optimized.
On the other, we don't yet support parameters given as part of the
include path attribute ... This needs to be implemented...
In fact turning to the Servlet 2.5 Spec, there is Section 8.1.1, Query
Strings in Request Dispatcher Paths, stating the request to support
query parameters. Also the JSP 2.1 spec in Section 5.6, <jsp:param>,
states that parameters follow the mechanism of Servlet Spec Section 8.1.1
So I think, Sling *must* support query parameters and a <sling:param>
tag would have to abide by the rules of the <jsp:param> tag (we might
even want to investigate, whether reusing <jsp:param> itself instead of
inventing our own makes more sense).
Patches welcome ;-)
Regards
Felix
>
> stefan
>
>