You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Georg Henzler <gh...@apache.org> on 2020/09/10 23:09:33 UTC
[DISCUSS] Automatic Mapping of URIs in HTL
Hi all,
as briefly mentioned in the thread about the resource
mapping SPI [1], it would be really useful if HTL
could auto-map URIs (regardless of the SPI)
- that way many projects that use the rewriting
pipeline [2] today for that purpose could simplify
their setup (and make it more performant). Now the
question is how to do this best, the following
options come to my mind:
1. Per URI as mentioned in template:
<a href="${'/content/path/to/page.html' @ mapUri}"/>
2. Turned on/off with a wrapper element
<sly data-sly-map-uris="true">
<a href="/content/path/to/page1.html"/>
<a href="/content/path/to/page2.html"/>
...
</sly>
3. Per global OSGi configuration
Now 1. is not very convenient (and would produce a
lot of noise in the template), 2. is probably the
most flexible and should make it fairly easy to run
the rewriting pipeline side by side with the new
approach at certain content paths, 3. is the easiest
to implement but it should at least allow to configure
a regex of content paths where auto-mapping applies
(to ensure the approaches can run side by side)
Are there other (better) ideas? Or more generally,
are there any concerns to move into this direction?
-Georg
[1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
[2]
https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Konrad Windszus <ko...@gmx.de>.
+1 for a dedicated option. Not sure about the naming though.
Konrad
> Am 11.09.2020 um 14:07 schrieb Radu Cotescu <ra...@apache.org>:
>
> Hi Georg,
>
>> On 11 Sep 2020, at 01:09, Georg Henzler <gh...@apache.org> wrote:
>>
>> Hi all,
>>
>> as briefly mentioned in the thread about the resource
>> mapping SPI [1], it would be really useful if HTL
>> could auto-map URIs (regardless of the SPI)
>> - that way many projects that use the rewriting
>> pipeline [2] today for that purpose could simplify
>> their setup (and make it more performant). Now the
>> question is how to do this best, the following
>> options come to my mind:
>>
>> 1. Per URI as mentioned in template:
>>
>> <a href="${'/content/path/to/page.html' @ mapUri}"/>
>
> This could work - it would be a Sling-specific option and we’ve done this in the past in https://issues.apache.org/jira/browse/SLING-5812 <https://issues.apache.org/jira/browse/SLING-5812>. The option would introduce a new runtime call to the new SPIs.
>
>
>>
>> 2. Turned on/off with a wrapper element
>>
>> <sly data-sly-map-uris="true">
>> <a href="/content/path/to/page1.html"/>
>> <a href="/content/path/to/page2.html"/>
>> ...
>> </sly>
>
> This introduces a new block element, which would require a specification enhancement. Given that URI mapping is Sling specific, I don’t think that such a proposal would be successful.
> In addition to that, the implementation would not be trivial - all child elements would have to be checked for attributes that allow URIs at compile time and add the previously mentioned runtime calls.
>
>>
>> 3. Per global OSGi configuration
>>
>> Now 1. is not very convenient (and would produce a
>> lot of noise in the template), 2. is probably the
>> most flexible and should make it fairly easy to run
>> the rewriting pipeline side by side with the new
>> approach at certain content paths, 3. is the easiest
>> to implement but it should at least allow to configure
>> a regex of content paths where auto-mapping applies
>> (to ensure the approaches can run side by side)
>
> How would we handle 3?
>
>>
>> Are there other (better) ideas? Or more generally,
>> are there any concerns to move into this direction?
>>
>> -Georg
>>
>> [1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
>> [2] https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
>
> Thanks,
> Radu
>
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Radu Cotescu <ra...@apache.org>.
Thanks, Georg! I’ll try to have a look this week.
Regards,
Radu
> On 23 Sep 2020, at 10:58, Georg Henzler <gh...@apache.org> wrote:
>
> I created issue SLING-9762 [1] for this.
>
> -Georg
>
> [1] https://issues.apache.org/jira/browse/SLING-9762
>
> On 2020-09-11 16:55, Georg Henzler wrote:
>> Hi Paul
>>> The reason I think both the global config and the local config are
>>> necessary
>> good point, +1 (both "global on/disable for one uri locally" and
>> "global off/enable for one uri locally" are valid use cases)
>>> .. JSON or some JS objects in HTL scripts (thinking on how many
>>> times I had to go back and change a Sling Model to add URI mapping, because
>>> a specific Sling-based product that uses a servlet filter does not/cannot
>>> map values in JS/JSON).
>> IIRC for this product only html paths are mapped (and js/json paths need to be
>> mapped manually). The idea of this proposal is to map _any_ uri or _none_
>> depending on the global config (and allow to override per uri via param)
>> -Georg
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Georg Henzler <gh...@apache.org>.
I created issue SLING-9762 [1] for this.
-Georg
[1] https://issues.apache.org/jira/browse/SLING-9762
On 2020-09-11 16:55, Georg Henzler wrote:
> Hi Paul
>
>> The reason I think both the global config and the local config are
>> necessary
>
> good point, +1 (both "global on/disable for one uri locally" and
> "global off/enable for one uri locally" are valid use cases)
>
>> .. JSON or some JS objects in HTL scripts (thinking on how many
>> times I had to go back and change a Sling Model to add URI mapping,
>> because
>> a specific Sling-based product that uses a servlet filter does
>> not/cannot
>> map values in JS/JSON).
>
> IIRC for this product only html paths are mapped (and js/json paths
> need to be
> mapped manually). The idea of this proposal is to map _any_ uri or
> _none_
> depending on the global config (and allow to override per uri via
> param)
>
>
> -Georg
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Georg Henzler <gh...@apache.org>.
Hi Paul
> The reason I think both the global config and the local config are
> necessary
good point, +1 (both "global on/disable for one uri locally" and
"global off/enable for one uri locally" are valid use cases)
> .. JSON or some JS objects in HTL scripts (thinking on how many
> times I had to go back and change a Sling Model to add URI mapping,
> because
> a specific Sling-based product that uses a servlet filter does
> not/cannot
> map values in JS/JSON).
IIRC for this product only html paths are mapped (and js/json paths need
to be
mapped manually). The idea of this proposal is to map _any_ uri or
_none_
depending on the global config (and allow to override per uri via param)
-Georg
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Paul Bjorkstrand <pa...@gmail.com>.
I like your idea of hooking into the existing URI context processing,
especially because you would want to have the mapping occur after URL
manipulation (I think). My thoughts based on what has been said above:
1. Hook into the existing URI context, and implement the processing
wherever URIs are processed (either automatic via context sensitive
handling built into HTL, or manual whenever context='uri' ise set for an
expression).
2. Have a configuration (CAConfig / OSGi / whatever) to drive whether to
map URIs or not for a given path and/or (super) resource type.
3. Have a local configuration to override the default that is set in the
previous value, like your mapUri, but with a boolean value to turn it
on/off (mapUri=true / mapUri=false)
The reason I think both the global config and the local config are
necessary: JSON or some JS objects in HTL scripts (thinking on how many
times I had to go back and change a Sling Model to add URI mapping, because
a specific Sling-based product that uses a servlet filter does not/cannot
map values in JS/JSON).
-Paul
On Fri, Sep 11, 2020 at 8:15 AM Georg Henzler <gh...@apache.org> wrote:
> Hi Radu,
>
>
> >> 1. Per URI as mentioned in template:
> >> <a href="${'/content/path/to/page.html' @ mapUri}"/>
> >
> > This could work - it would be a Sling-specific option and we’ve done
> > this in the past in https://issues.apache.org/jira/browse/SLING-5812
> > <https://issues.apache.org/jira/browse/SLING-5812>. The option would
> > introduce a new runtime call to the new SPIs.
>
> I quickly tested this with minor changes to
> URIManipulationFilterExtension
> and URIManipulationFilter and it worked fine - but as said it's
> tedious and error prone to go this route, it should rather be a cross
> cutting concern
>
> >> 3. Per global OSGi configuration
> >>
> > How would we handle 3?
>
> So one simple naive way would be to hook into [1], check for the
> "uri" context and call the map API method on the value. The probably
> clean way (I don't know this code very well) is to create a dedicated
> filter that gets to see all properties similar to the XSSFilter (and
> adjusts uri values only).
>
> I also think conceptually it also fits in well with the "automatic
> context sensitivity" in the spec [2] (just another aspect compared to
> XSS). While the template/spec does not change, the implementation
> takes care of the handling and configuration, this is true for XSS
> today and would also hold true for mapping of URIs.
>
> -Georg
>
>
> [1]
>
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/blob/eb8891e89caef2993f4cdab0fbe764a7695ec0e8/src/main/java/org/apache/sling/scripting/sightly/impl/filter/XSSFilter.java#L51
>
> [2]
>
> https://github.com/adobe/htl-spec/blob/1.2/SPECIFICATION.md#113-context-sensitive
>
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Georg Henzler <gh...@apache.org>.
Hi Radu,
>> 1. Per URI as mentioned in template:
>> <a href="${'/content/path/to/page.html' @ mapUri}"/>
>
> This could work - it would be a Sling-specific option and we’ve done
> this in the past in https://issues.apache.org/jira/browse/SLING-5812
> <https://issues.apache.org/jira/browse/SLING-5812>. The option would
> introduce a new runtime call to the new SPIs.
I quickly tested this with minor changes to
URIManipulationFilterExtension
and URIManipulationFilter and it worked fine - but as said it's
tedious and error prone to go this route, it should rather be a cross
cutting concern
>> 3. Per global OSGi configuration
>>
> How would we handle 3?
So one simple naive way would be to hook into [1], check for the
"uri" context and call the map API method on the value. The probably
clean way (I don't know this code very well) is to create a dedicated
filter that gets to see all properties similar to the XSSFilter (and
adjusts uri values only).
I also think conceptually it also fits in well with the "automatic
context sensitivity" in the spec [2] (just another aspect compared to
XSS). While the template/spec does not change, the implementation
takes care of the handling and configuration, this is true for XSS
today and would also hold true for mapping of URIs.
-Georg
[1]
https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/blob/eb8891e89caef2993f4cdab0fbe764a7695ec0e8/src/main/java/org/apache/sling/scripting/sightly/impl/filter/XSSFilter.java#L51
[2]
https://github.com/adobe/htl-spec/blob/1.2/SPECIFICATION.md#113-context-sensitive
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Radu Cotescu <ra...@apache.org>.
Hi Georg,
> On 11 Sep 2020, at 01:09, Georg Henzler <gh...@apache.org> wrote:
>
> Hi all,
>
> as briefly mentioned in the thread about the resource
> mapping SPI [1], it would be really useful if HTL
> could auto-map URIs (regardless of the SPI)
> - that way many projects that use the rewriting
> pipeline [2] today for that purpose could simplify
> their setup (and make it more performant). Now the
> question is how to do this best, the following
> options come to my mind:
>
> 1. Per URI as mentioned in template:
>
> <a href="${'/content/path/to/page.html' @ mapUri}"/>
This could work - it would be a Sling-specific option and we’ve done this in the past in https://issues.apache.org/jira/browse/SLING-5812 <https://issues.apache.org/jira/browse/SLING-5812>. The option would introduce a new runtime call to the new SPIs.
>
> 2. Turned on/off with a wrapper element
>
> <sly data-sly-map-uris="true">
> <a href="/content/path/to/page1.html"/>
> <a href="/content/path/to/page2.html"/>
> ...
> </sly>
This introduces a new block element, which would require a specification enhancement. Given that URI mapping is Sling specific, I don’t think that such a proposal would be successful.
In addition to that, the implementation would not be trivial - all child elements would have to be checked for attributes that allow URIs at compile time and add the previously mentioned runtime calls.
>
> 3. Per global OSGi configuration
>
> Now 1. is not very convenient (and would produce a
> lot of noise in the template), 2. is probably the
> most flexible and should make it fairly easy to run
> the rewriting pipeline side by side with the new
> approach at certain content paths, 3. is the easiest
> to implement but it should at least allow to configure
> a regex of content paths where auto-mapping applies
> (to ensure the approaches can run side by side)
How would we handle 3?
>
> Are there other (better) ideas? Or more generally,
> are there any concerns to move into this direction?
>
> -Georg
>
> [1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
> [2] https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
Thanks,
Radu
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Georg Henzler <gh...@apache.org>.
Hi Nicolas,
yes that makes sense, although maybe a bit overkill for
one boolean flag it's conceptually cleaner than OSGi config
with regex (no 3). Overall the question will be if this
needs to be controlled per content root path or rather per
(super)resourceType... Output Rewriting Pipelines allow for
both variants [1] but not sure if we need both here as well...
-Georg
[1]
https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html#configuring-a-processor
On 2020-09-11 10:02, Nicolas Peltier wrote:
> i like the idea! what about a context aware configuration?
>
> Le ven. 11 sept. 2020 à 01:09, Georg Henzler <gh...@apache.org> a
> écrit :
>
>> Hi all,
>>
>> as briefly mentioned in the thread about the resource
>> mapping SPI [1], it would be really useful if HTL
>> could auto-map URIs (regardless of the SPI)
>> - that way many projects that use the rewriting
>> pipeline [2] today for that purpose could simplify
>> their setup (and make it more performant). Now the
>> question is how to do this best, the following
>> options come to my mind:
>>
>> 1. Per URI as mentioned in template:
>>
>> <a href="${'/content/path/to/page.html' @ mapUri}"/>
>>
>> 2. Turned on/off with a wrapper element
>>
>> <sly data-sly-map-uris="true">
>> <a href="/content/path/to/page1.html"/>
>> <a href="/content/path/to/page2.html"/>
>> ...
>> </sly>
>>
>> 3. Per global OSGi configuration
>>
>> Now 1. is not very convenient (and would produce a
>> lot of noise in the template), 2. is probably the
>> most flexible and should make it fairly easy to run
>> the rewriting pipeline side by side with the new
>> approach at certain content paths, 3. is the easiest
>> to implement but it should at least allow to configure
>> a regex of content paths where auto-mapping applies
>> (to ensure the approaches can run side by side)
>>
>> Are there other (better) ideas? Or more generally,
>> are there any concerns to move into this direction?
>>
>> -Georg
>>
>> [1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
>> [2]
>>
>> https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
>>
Re: [DISCUSS] Automatic Mapping of URIs in HTL
Posted by Nicolas Peltier <pe...@gmail.com>.
i like the idea! what about a context aware configuration?
Le ven. 11 sept. 2020 à 01:09, Georg Henzler <gh...@apache.org> a écrit :
> Hi all,
>
> as briefly mentioned in the thread about the resource
> mapping SPI [1], it would be really useful if HTL
> could auto-map URIs (regardless of the SPI)
> - that way many projects that use the rewriting
> pipeline [2] today for that purpose could simplify
> their setup (and make it more performant). Now the
> question is how to do this best, the following
> options come to my mind:
>
> 1. Per URI as mentioned in template:
>
> <a href="${'/content/path/to/page.html' @ mapUri}"/>
>
> 2. Turned on/off with a wrapper element
>
> <sly data-sly-map-uris="true">
> <a href="/content/path/to/page1.html"/>
> <a href="/content/path/to/page2.html"/>
> ...
> </sly>
>
> 3. Per global OSGi configuration
>
> Now 1. is not very convenient (and would produce a
> lot of noise in the template), 2. is probably the
> most flexible and should make it fairly easy to run
> the rewriting pipeline side by side with the new
> approach at certain content paths, 3. is the easiest
> to implement but it should at least allow to configure
> a regex of content paths where auto-mapping applies
> (to ensure the approaches can run side by side)
>
> Are there other (better) ideas? Or more generally,
> are there any concerns to move into this direction?
>
> -Georg
>
> [1] https://www.mail-archive.com/dev@sling.apache.org/msg97820.html
> [2]
>
> https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
>