Hi Rob,
The RuntimeExtensions are meant to process the outcome of a Sightly
expression. If such an extension would need to perform some processing
based on component resolution it's fair to pass it the same resolver that
the ServletResolver used.
I'll document in the RenderContext that this resol
iday, January 23, 2015 5:58 AM
> To: dev@sling.apache.org
> Subject: Re: [Sightly] provide access to the Script Resource Resolver in
> RenderContext
>
> Hi
>
> I am a bit hesitant with shipping ResourceResolver instances around. But
> since this is for an extension of
session in Oak degrades performance
rapidly.
-Rob
-Original Message-
From: Felix Meschberger [mailto:fmesc...@adobe.com]
Sent: Friday, January 23, 2015 5:58 AM
To: dev@sling.apache.org
Subject: Re: [Sightly] provide access to the Script Resource Resolver in
RenderContext
Hi
I am a bi
Hi
I am a bit hesitant with shipping ResourceResolver instances around. But since
this is for an extension of the scripting language, this might make sense. We
just have to properly document that this is not the request processing
ResourceResolver but the ServletResolver’s ResourceResolver whic
Hi,
There are cases when Sightly RuntimeExtensions might need to access the
repository. Since creating multiple ResourceResolvers is not a cheap
operation, especially with Jackrabbit, wouldn't it be better to enhance the
RenderContext to make it provide the ResourceResolver available in the
Script