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/engin
>>>> e/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension
>>>> /ResourceRuntimeExtension.java?view=markup#l247
>>>> <http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/engi
>>>> ne/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extensio
>>>> n/ResourceRuntimeExtension.java?view=markup#l247>
>>>> <
>>>>
>>>> http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/engin
>>>> e/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension
>>>> /ResourceRuntimeExtension.java?view=markup#l247
>>>> <http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/sightly/engi
>>>> ne/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extensio
>>>> n/ResourceRuntimeExtension.java?view=markup#l247>
>
