+1 for a dedicated option. Not sure about the naming though.
Konrad
> Am 11.09.2020 um 14:07 schrieb Radu Cotescu <[email protected]>:
>
> Hi Georg,
>
>> On 11 Sep 2020, at 01:09, Georg Henzler <[email protected]> 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/[email protected]/msg97820.html
>> [2]
>> https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html
>
> Thanks,
> Radu
>
