Hi Dirk,
You're correct, the HTTP headers have to be accessed with the Use-API:
<div data-sly-use.headers="headers.js" data-sly-test="${headers.referer}">
Request has referer: ${headers.referer}
</div>
And the headers.js file would look as follows (could be done in Java as
well):
use(function () {
return {
referer: request.getHeader('Referer')
};
});
For the template, you could have something like the following templates:
<template data-sly-template.include="${@ resource}"
data-sly-use.headers="headers.js">
<sly data-sly-test="${headers.supportsSSI}"
data-sly-unwrap><!--#include file="${resource}.html" --></sly>
<sly data-sly-test="${! headers.supportsSSI}"
data-sly-resource="${resource}" data-sly-unwrap/>
</template>
Which can then be used as follows:
<div data-sly-call="${include @ resource='foo'}"></div>
You could also split the template in various sub-templates as you are
suggesting, in order to call specifically the one or the other inclusion
mechanism.
So far, the only predefined Sightly templates are in AEM:
/libs/granite/sightly/templates/clientlib.html
/libs/cq/personalization/sightly/personalization.html
Best,
Gabriel
On 09/04/15 16:21, "Dirk Rudolph" <[email protected]> wrote:
>Hi Gabriel,
>
>with this point of view I fully agree with you.
>
>Contributing something reusable might be difficult as it isn’t fully
>clear for me how the template should look like. I would assume that there
>is a template that calls various other templates depending on the given
>capabilities and the specified include behaviour:
>
><div data-sly-call=“${include @ resource=resoruce, mode=‘ssi’}” />
>
>would call
>
><div data-sly-call=“${include.ssi @ resource=resource}”/>
>
>but only if SSIs are possible, otherwise it would do:
>
><div data-sly-resource=“…” />
>
>In my projects I used HTTP headers to specify whether a special
>capability is supported by the webfrontend. As request headers are not
>available in sightly so far (as far as I know) the template would require
>a Use instance to access them and evaluate if the required capability is
>provided for the current request.
>
>Last but not least: Are there already some predefined template provided
>by Sling?
>
>Cheers,
>Dirk
>
>> On 08 Apr 2015, at 12:38, Gabriel Walt <[email protected]> wrote:
>>
>>
>> Hi Dirk,
>>
>> It is possible to do what you describe with data-sly-template. The two
>> statements data-sly-template and data-sly-use are the extension points
>> that allow to do in Sightly what TagLibs and Scriptlets do in JSP.
>>
>> What you said for JSP is even more true for Sightly: In times of
>>Sightly,
>> it is easy (actually much easier than to create a custom TagLib) to
>> implement a custom include template that delegates to data-sly-resource
>> when the include should be done directly. :)
>>
>> I strongly discourage to build custom Sightly extensions, like creating
>>a
>> decorator around the ResourcePlugin. If we think that some features are
>> lacking, then let's take a step back and analyze if something might make
>> sense to be added to the core, so that everybody can benefit from it.
>>The
>> frustrating part here is that we want to keep the language focused, so
>> many good ideas won't make it. But luckily, this cannot be blocking on a
>> project level since the data-sly-template and data-sly-use extension
>> points usually allow to achieve what is needed.
>>
>> While I really like your suggestion to have different ways of including
>>a
>> resource, I'm not convinced yet of the benefit to add that to the core
>> features, as opposed to keeping it in a template. The reason is that
>>there
>> are many different kind of includes (SSI, ESI, Ajax, etc.), and each has
>> many very different features, which would mean that we'll end up adding
>> all kinds of additional options to data-sly-resource for each of these
>> includes. Actually, each of these include systems is a template language
>> in itself, which really makes me think that this is best handled in a
>> separate template where you can write whatever instructions are needed,
>> and each project still has the possibility to fully overlay whatever
>>that
>> template proposes.
>>
>> Still, what would be great is that Sling comes with a predefined
>>template
>> that offers to easily call different kind of includes. Dirk, would you
>>be
>> ready to contribute something like that?
>>
>> Cheers,
>> Gabriel
>>
>>
>> On 08/04/15 10:28, "Dirk Rudolph" <[email protected]> wrote:
>>
>>> Thanks for you feedback.
>>>
>>> So you suggest to implement a decorator around ResourcePlugin.FUNCTION
>>> for handling different behaviours. I¹m fine with this.
>>>
>>> However wouldn¹t it make sense to provide a central extension point for
>>> that use case? In my eyes it is quite common to use different include
>>> behaviours for at least those projects I did with Sling/AEM.
>>> Cheers,
>>>
>>> Dirk
>>>
>>>> On 08 Apr 2015, at 10:07, Vlad Bailescu <[email protected]> wrote:
>>>>
>>>> Hey Dirk,
>>>>
>>>> The way to go about doing this at the moment is to provide your own
>>>> RuntimeExtension (with a higher service ranking).
>>>>
>>>> Best,
>>>> Vlad
>>>>
>>>> On Tue, Apr 7, 2015 at 12:46 PM, Dirk Rudolph
>>>> <[email protected] <mailto:[email protected]>>
>>>> wrote:
>>>>
>>>>> Hi @devs,
>>>>>
>>>>> while working on a project with a default Apache Sling based
>>>>> AEM6+Dispatcher infrastructure, we mentioned, that there is no way to
>>>>> provide a different include behaviour for resource includes - for
>>>>> example
>>>>> include using SSI instead of directly calling the RequestDispatcher.
>>>>>
>>>>> In times of JSPs it was easy to implement a custom include tag the
>>>>> delegates to the <sling:include/> when the include should be done
>>>>> directly.
>>>>> Unfortunately this isn¹t possible with Sightly so far (and as I
>>>>> understood
>>>>> this is also intended to be not possible).
>>>>>
>>>>> Nevertheless it would be nice to have the possibility to use
>>>>>different
>>>>> behaviours for resource includes also in sightly. I had a look at the
>>>>> implementation and in general it would mean to expose the
>>>>> includeResource
>>>>> method in [1] in a SPI that will be implemented per behaviour
>>>>> identified by
>>>>> an option in the sightly template:
>>>>>
>>>>> <section data-sly-resource="${ 'path/to/resource' @
>>>>>mode=Œ<behaviour>'
>>>>> }"></section>
>>>>>
>>>>> The default behaviour of directly including the resource would stay
>>>>>the
>>>>> same (when mode isn¹t specified) and would also be the fallback when
>>>>> the
>>>>> specified behaviour isn¹t available. So the suggestion is fully
>>>>> compatible
>>>>> with previous versions of sightly.
>>>>>
>>>>> What do you thing?/comments appreciated.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> ---
>>>>> Dirk Rudolph | Senior Software Engineer
>>>>>
>>>>> Netcentric AG
>>>>>
>>>>> M: +41 79 642 37 11
>>>>> D: +49 174 966 84 34
>>>>>
>>>>> [email protected] <mailto:[email protected]>
>>>>> <mailto:[email protected]
>>>>> <mailto:[email protected]>> |
>>>>> www.netcentric.biz <http://www.netcentric.biz/>
>>>>> <http://www.netcentric.biz/ <http://www.netcentric.biz/>>[1]
>>>>>
>>>>>
>>>>>http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/eng
>>>>>in
>>>>>
>>>>>e/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extensi
>>>>>on
>>>>> /ResourceRuntimeExtension.java?view=markup#l247
>>>>>
>>>>><http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/en
>>>>>gi
>>>>>
>>>>>ne/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extens
>>>>>io
>>>>> n/ResourceRuntimeExtension.java?view=markup#l247>
>>>>> <
>>>>>
>>>>>
>>>>>http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/eng
>>>>>in
>>>>>
>>>>>e/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extensi
>>>>>on
>>>>> /ResourceRuntimeExtension.java?view=markup#l247
>>>>>
>>>>><http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/en
>>>>>gi
>>>>>
>>>>>ne/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extens
>>>>>io
>>>>> n/ResourceRuntimeExtension.java?view=markup#l247>
>>
