If we can keep the <sling:include/> tag easy to understand, I would be happy with such an approach. I fear, however, that it could get overly complicated.
Just for consideration, I see these two use-cases: * include a resource (currently <sling:include/>); this typically re-dispatches the request internally * modularize rendering scripts (currently <sling:call/>); this does not re-dispatch the request, the context remains the same Do the two use-cases justify separate tags? I don't know. Regards Julian On Fri, Aug 22, 2014 at 12:56 PM, Carsten Ziegeler <[email protected]> wrote: > I would be in favour of having just one tag, the include one - so if I see > it correctly the only problem is that it changes the set of visible > selectors. So if we allow a way to deal with that with the include tag, we > have a single tag and people have not to wonder which tag to use when. > > Carsten > > > 2014-08-22 12:51 GMT+02:00 Julian Sedding <[email protected]>: > >> Yes, I would be in favour of deprecating <sling:call/>. It never felt >> very "slingish". If we can also get rid of <sling:eval/>, I believe we >> could even simplify the ServletResolver and remove the methods that >> were presumably added to support these tags. >> >> One option could be to extend the <sling:call/> tag in the following >> fashion: >> * deprecate "script" attribute >> * if the "script" attribute is present, remove the extension (i.e. >> last dot) and interpret as selectorString >> * add new attribute "selectors", which is implemented like the >> proposed <sling:partial/> tag >> >> Unless I am missing something, this would provide backwards >> compatibility, while at the same time supporting Gabriel's use-case. >> >> Regards >> Julian >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
