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:fmesc...@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 >> >>
