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
> 
> 

Reply via email to