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
