You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2014/08/02 03:14:58 UTC
Re: Script language independent overrides
On 24.07.2014, at 19:11, Justin Edelson <ju...@justinedelson.com> wrote:
> If the author didn't want to
> do that, they shouldn't use sling:call and instead use sling:include
> with replaceSelectors.
Right. sling:call addresses the script and that is simply wrong - it needs to be a sling:include and strictly rely on sling resource resolution (selectors, extensions etc.). If you use sling:call and address the script, you of course tie yourself to the script engine in question (i.e. usually JSP).
Cheers,
Alex
Re: Script language independent overrides
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
IMHO <sling:call> solves a specific problem but at the end of the day is a Sling Anti-Pattern. I am not very happy to evolve this beyond the basic functionality.
The Sling-correct way to render stuff is to use <sling:include> (or <sling:forward> if you will). As such I agree with Carsten to suggest converting the code to use <sling:include>.
In fact, the <sling:include> allows you to set a resource type along with the resource (relative) path which may create a virtual resource with the given resource type if the named resource does not exist and thus then execute the respective rendering
Regards
Felix
Am 22.08.2014 um 10:50 schrieb Gabriel Walt <gw...@adobe.com>:
>
> Thanks for your answers! Let me try to provide more context and be more
> specific.
>
> With sling:resourceSuperType (or with /apps /libs overlaying), you can
> customize any script of your component. A common practice is to split
> large script templates into partials that can then each be independently
> customized, to avoid full script duplication, and to adapt only parts
> of it.
>
> The typical example is a page component that can for instance end up with
> a structure like:
> - page.jsp
> - head.jsp
> - headlibs.jsp
> - body.jsp
> - top.jsp
> - content.jsp
> - bottom.jsp
> - bodylibs.jsp
>
> These scripts are usually all included with something like a sling:call,
> but then this makes it impossible in an extending component to use a
> different script language than the one used in the super-type (so in our
> example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc).
>
> Thus, it would be nice to be able to do an include of script partials that
> are not binding to a particular script language, like for instance:
> <sling:call script="myscript.*" />
> instead of:
> <sling:call script="myscript.jsp" />
>
> Best,
> Gabriel
>
>
Re: Script language independent overrides
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
Adding more options to sling:include makes perfect sense, but changing
the behavior of sling:call does not. When I write
<sling:call script="foo.jsp"/>
I mean "call the script foo.jsp". I don't mean "call any script named foo."
Regards,
Justin
On Fri, Aug 22, 2014 at 6:51 AM, Julian Sedding <js...@gmail.com> wrote:
> 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
Re: Script language independent overrides
Posted by Julian Sedding <js...@gmail.com>.
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 <cz...@apache.org> 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 <js...@gmail.com>:
>
>> 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
> cziegeler@apache.org
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <js...@gmail.com>:
> 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
cziegeler@apache.org
Re: Script language independent overrides
Posted by Julian Sedding <js...@gmail.com>.
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
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
If you pass in the resource object into include, no resource solution is
done, though it changes the selectors.
Instead of adding another tag which makes it more unclear, whether to use
include, call, or partial - why not add an option to the include tag?
And if call has been invented to circumvent the above things, why not
deprecate it then?
Carsten
2014-08-22 12:30 GMT+02:00 Julian Sedding <js...@gmail.com>:
> The approach mentioned by Carsten has two drawbacks:
> * it changes the selectors seen by any scripts included further down
> the include stack (IIRC this was the reason why <sling:call/> was
> introduced in the first place)
> * resourceResolution has to be done again, even though we know we want
> to render the same resource (maybe <sling:include
> resource="${resource}"/> also prevents this, I didn't check)
>
> I created SLING-3874[0] with a proof-of-concept implementation for a
> <sling:partial/> tag. This allows selecting another rendering script
> for the current resource with the specified selector. Downstream
> includes are not affected by this, however.
>
> Example page.jsp (see Gabriel's example above):
> <html>
> <sling:partial selectors="head"/>
> <sling:partial selectors="body"/>
> </html>
>
> Regards
> Julian
>
> [0] https://issues.apache.org/jira/browse/SLING-3874
>
> On Fri, Aug 22, 2014 at 12:11 PM, Gabriel Walt <gw...@adobe.com> wrote:
> >
> > Wow, couldn't believe this was working, very nice!! :)
> >
> > Thanks!
> >
> >
> > On 22/08/14 11:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
> >
> >>You can simply use sling:include instead, add a selector and your script
> >>act on that specific selector - that's language independent.
> >>
> >>Carsten
> >>
> >>
> >>2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
> >>
> >>>
> >>> Thanks for your answers! Let me try to provide more context and be more
> >>> specific.
> >>>
> >>> With sling:resourceSuperType (or with /apps /libs overlaying), you can
> >>> customize any script of your component. A common practice is to split
> >>> large script templates into partials that can then each be
> independently
> >>> customized, to avoid full script duplication, and to adapt only parts
> >>> of it.
> >>>
> >>> The typical example is a page component that can for instance end up
> >>>with
> >>> a structure like:
> >>> - page.jsp
> >>> - head.jsp
> >>> - headlibs.jsp
> >>> - body.jsp
> >>> - top.jsp
> >>> - content.jsp
> >>> - bottom.jsp
> >>> - bodylibs.jsp
> >>>
> >>> These scripts are usually all included with something like a
> sling:call,
> >>> but then this makes it impossible in an extending component to use a
> >>> different script language than the one used in the super-type (so in
> our
> >>> example we'd be forced to go with JSP, and couldn't use ESP, Sightly,
> >>>etc).
> >>>
> >>> Thus, it would be nice to be able to do an include of script partials
> >>>that
> >>> are not binding to a particular script language, like for instance:
> >>> <sling:call script="myscript.*" />
> >>> instead of:
> >>> <sling:call script="myscript.jsp" />
> >>>
> >>> Best,
> >>> Gabriel
> >>>
> >>>
> >>>
> >>
> >>
> >>--
> >>Carsten Ziegeler
> >>Adobe Research Switzerland
> >>cziegeler@apache.org
> >
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Script language independent overrides
Posted by Julian Sedding <js...@gmail.com>.
The approach mentioned by Carsten has two drawbacks:
* it changes the selectors seen by any scripts included further down
the include stack (IIRC this was the reason why <sling:call/> was
introduced in the first place)
* resourceResolution has to be done again, even though we know we want
to render the same resource (maybe <sling:include
resource="${resource}"/> also prevents this, I didn't check)
I created SLING-3874[0] with a proof-of-concept implementation for a
<sling:partial/> tag. This allows selecting another rendering script
for the current resource with the specified selector. Downstream
includes are not affected by this, however.
Example page.jsp (see Gabriel's example above):
<html>
<sling:partial selectors="head"/>
<sling:partial selectors="body"/>
</html>
Regards
Julian
[0] https://issues.apache.org/jira/browse/SLING-3874
On Fri, Aug 22, 2014 at 12:11 PM, Gabriel Walt <gw...@adobe.com> wrote:
>
> Wow, couldn't believe this was working, very nice!! :)
>
> Thanks!
>
>
> On 22/08/14 11:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
>
>>You can simply use sling:include instead, add a selector and your script
>>act on that specific selector - that's language independent.
>>
>>Carsten
>>
>>
>>2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>>
>>>
>>> Thanks for your answers! Let me try to provide more context and be more
>>> specific.
>>>
>>> With sling:resourceSuperType (or with /apps /libs overlaying), you can
>>> customize any script of your component. A common practice is to split
>>> large script templates into partials that can then each be independently
>>> customized, to avoid full script duplication, and to adapt only parts
>>> of it.
>>>
>>> The typical example is a page component that can for instance end up
>>>with
>>> a structure like:
>>> - page.jsp
>>> - head.jsp
>>> - headlibs.jsp
>>> - body.jsp
>>> - top.jsp
>>> - content.jsp
>>> - bottom.jsp
>>> - bodylibs.jsp
>>>
>>> These scripts are usually all included with something like a sling:call,
>>> but then this makes it impossible in an extending component to use a
>>> different script language than the one used in the super-type (so in our
>>> example we'd be forced to go with JSP, and couldn't use ESP, Sightly,
>>>etc).
>>>
>>> Thus, it would be nice to be able to do an include of script partials
>>>that
>>> are not binding to a particular script language, like for instance:
>>> <sling:call script="myscript.*" />
>>> instead of:
>>> <sling:call script="myscript.jsp" />
>>>
>>> Best,
>>> Gabriel
>>>
>>>
>>>
>>
>>
>>--
>>Carsten Ziegeler
>>Adobe Research Switzerland
>>cziegeler@apache.org
>
Re: Script language independent overrides
Posted by Gabriel Walt <gw...@adobe.com>.
Wow, couldn't believe this was working, very nice!! :)
Thanks!
On 22/08/14 11:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
>You can simply use sling:include instead, add a selector and your script
>act on that specific selector - that's language independent.
>
>Carsten
>
>
>2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>
>>
>> Thanks for your answers! Let me try to provide more context and be more
>> specific.
>>
>> With sling:resourceSuperType (or with /apps /libs overlaying), you can
>> customize any script of your component. A common practice is to split
>> large script templates into partials that can then each be independently
>> customized, to avoid full script duplication, and to adapt only parts
>> of it.
>>
>> The typical example is a page component that can for instance end up
>>with
>> a structure like:
>> - page.jsp
>> - head.jsp
>> - headlibs.jsp
>> - body.jsp
>> - top.jsp
>> - content.jsp
>> - bottom.jsp
>> - bodylibs.jsp
>>
>> These scripts are usually all included with something like a sling:call,
>> but then this makes it impossible in an extending component to use a
>> different script language than the one used in the super-type (so in our
>> example we'd be forced to go with JSP, and couldn't use ESP, Sightly,
>>etc).
>>
>> Thus, it would be nice to be able to do an include of script partials
>>that
>> are not binding to a particular script language, like for instance:
>> <sling:call script="myscript.*" />
>> instead of:
>> <sling:call script="myscript.jsp" />
>>
>> Best,
>> Gabriel
>>
>>
>>
>
>
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
You can simply use sling:include instead, add a selector and your script
act on that specific selector - that's language independent.
Carsten
2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>
> Thanks for your answers! Let me try to provide more context and be more
> specific.
>
> With sling:resourceSuperType (or with /apps /libs overlaying), you can
> customize any script of your component. A common practice is to split
> large script templates into partials that can then each be independently
> customized, to avoid full script duplication, and to adapt only parts
> of it.
>
> The typical example is a page component that can for instance end up with
> a structure like:
> - page.jsp
> - head.jsp
> - headlibs.jsp
> - body.jsp
> - top.jsp
> - content.jsp
> - bottom.jsp
> - bodylibs.jsp
>
> These scripts are usually all included with something like a sling:call,
> but then this makes it impossible in an extending component to use a
> different script language than the one used in the super-type (so in our
> example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc).
>
> Thus, it would be nice to be able to do an include of script partials that
> are not binding to a particular script language, like for instance:
> <sling:call script="myscript.*" />
> instead of:
> <sling:call script="myscript.jsp" />
>
> Best,
> Gabriel
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Script language independent overrides
Posted by Gabriel Walt <gw...@adobe.com>.
Thanks for your answers! Let me try to provide more context and be more
specific.
With sling:resourceSuperType (or with /apps /libs overlaying), you can
customize any script of your component. A common practice is to split
large script templates into partials that can then each be independently
customized, to avoid full script duplication, and to adapt only parts
of it.
The typical example is a page component that can for instance end up with
a structure like:
- page.jsp
- head.jsp
- headlibs.jsp
- body.jsp
- top.jsp
- content.jsp
- bottom.jsp
- bodylibs.jsp
These scripts are usually all included with something like a sling:call,
but then this makes it impossible in an extending component to use a
different script language than the one used in the super-type (so in our
example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc).
Thus, it would be nice to be able to do an include of script partials that
are not binding to a particular script language, like for instance:
<sling:call script="myscript.*" />
instead of:
<sling:call script="myscript.jsp" />
Best,
Gabriel