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:[email protected]] >> Sent: Tuesday, March 31, 2009 8:48 AM >> To: [email protected] >> 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 >>> >>> >
