Georg, one of the things that have to be considered here as well are links in a href tags in text properties (eg from a rich text editor) in sling model rendered output and in html rendered output
Ruben -----Original Message----- From: Georg Henzler <ghenz...@apache.org> Sent: Sunday, March 29, 2020 5:13 PM To: dev@sling.apache.org Subject: [DISCUSS] Resource Mapping SPI Hi all, so to eventually follow up on what has been discussed at last year's adaptTo Hackathon and in the mailing list afterwards [1]/[2] - I now found the time to draft the proposal for a Resource Mapping SPI. Two important points before we start: * This is not meant to replace the Rewriting Pipelines as they exist today - it just would allow some Sling setups (maybe > 70%?) to move to a simpler solution avoiding the overhead of the rewriter pipeline while obviously losing its flexibility, but for many that will be ok (I fully agree with Bertrand [3] here) * Let's focus the discussion first on if we would like to go into this direction instead of details (like mutable vs. immutable or naming, we can have detailed discussions around it once we decide to move on) But now to the actual proposal to introduce two new interfaces to the Sling API: ResourceURI: On Sling API level we treat links as strings (e.g. rr.map() returns a String). Using Strings for links has produced many bugs in the past, I think having an abstraction for a URI/link that is tailored for Sling would help a lot (obviously plain JDK URI can be used, but there is no support for selectors, suffix etc.). Besides being generally a good idea IMHO, ResourceURI shall be used for the other interface: ResourceMapper: Allows to hook into the rr.resolve() and rr.map() by implementing exactly those two methods that work on instances of ResourceURI. The idea is that n OSGi service instances of ResourceMapper build a pipeline of mappers that rr would run through when rr.resolve() or rr.map() is called (in the opposite direction for map). The request is passed in as context to both methods but may be null as it is today, implementations of ResourceMapper need to be able to handle null. The following mechanisms exist today for resource mapping in ootb Sling: * Config "resource.resolver.mapping" in JcrResourceResolverFactoryImpl * Mappings via /etc/map * Vanity Paths * sling:alias Those could be broken up into four implementations of ResourceMapper that are configured by default. About backwards-compatibility/breaking existing implementations: So this is a BIG CHANGE. However to keep it safe I would start with exactly one ResourceMapper active that is backed by today's implementation. The next step is to break it in separate resource mappers (as mentioned above) and just put them in a row. The Resource Mapping SPI would bring the following benefits: * Being able to hook into the resource mapping via SPI allows for flexibility that is otherwise only possible Rewriting Pipelines - while link rewriting/checking is the only reason most projects use Rewriting Pipelines (with all its performance overhead) * Extending the mapping process via a well-defined API that allows to write Touring-complete code is better than working with Strings in the Transformer (also for many cases it can be cleaner and better 'unit-testable' than /etc/maps) * HTL there can be an option to automatically map all attributes of context uri (better performance, better for debugging if map() is called synchronously) * Introducing the interface ResourceURI (with a backing helper class for everybody to use) is useful in general See branch [4] for some first code of the proposal, in particular ResourceMapping.java [5] and ResourceURI.java [6] -Georg [1] "[hackathon] externalization / resource mapping / rewriter" https://www.mail-archive.com/dev@sling.apache.org/msg87736.html [2] "Why get rid of the rewriter?" https://www.mail-archive.com/dev@sling.apache.org/msg87867.html [3] https://www.mail-archive.com/dev@sling.apache.org/msg87855.html [4] https://github.com/apache/sling-org-apache-sling-api/compare/feature/Resource_Mapping_SPI [5] https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java [6] https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/uri/ResourceURI.java On 2020-01-17 10:45, Georg Henzler wrote: > Hi Konrad, > > I think SLING-9005 is a good idea, but that is independent. > > My idea idea was to leave resourceResolver.map() unchanged (as there > is a lot of code using it out there, also it makes conceptually sense > as is). Rather I‘d like to provide an SPI that allows to customize the > way of the behavior of resourceResolver.map() - I‘m thinking of a > ranked list of ResourceMapper services (default one being today’s > behavior). Robert also has done some work into this direction already, > I‘d like to extend on that. > > I‘m currently on vacation but I have it on my list for when I‘m back. > > -Georg > >> >> On 16. Jan 2020, at 15:01, Konrad Windszus <konra...@gmx.de> wrote: >> >> I would like to revive this. >> >> @Georg: IIRC you wanted to come up with a proposal for a externalizer >> API. Are you working on this? >> Can we start by creating a JIRA ticket? >> >> There has been a related ticket opened today: >> https://issues.apache.org/jira/browse/SLING-9005 >> <https://issues.apache.org/jira/browse/SLING-9005> >> >> Konrad >> >>> On 5. Sep 2019, at 17:54, Jason E Bailey <jason.bai...@24601.org> >>> wrote: >>> >>> Specifically with regard to the re-writer >>> >>> I'm working on a replacement for this which I'm currently calling >>> the transformer -> >>> https://github.com/apache/sling-whiteboard/tree/master/transformer >>> >>> 1. It uses an HTML tokenizer that was added to the HTML utilities to >>> generate a stream of elements that can be modified and recombined. >>> It's much faster then tagsoup or jsoup since it's not trying to >>> build a valid document. This also means that it supports anything >>> that you write out in html. HTML4,5+ >>> >>> 2. It uses services with an ordering priority and does pattern >>> matching so that you can fine tune when the transformer is applied >>> >>> 3. The specific use case I was working on is creating a CSP header >>> with a nonce or hash attribute to lock down the javascript that's on >>> the page. >>> >>> It's currently working but it's not finished. >>> Are there other problems with the rewriter that I haven't addressed? >>> >>> >>> -- >>> Jason >>> >>>> On Thu, Sep 5, 2019, at 10:34 AM, Stefan Seifert wrote: >>>> >>>> - resource mapping >>>> - add a new SPI to define the mapping >>>> - add a default impl that reads the mapping from /etc/map as it is >>>> done today >>>> - possible to override with service ranking >>>> - but: there is already the ResourceMapper interface >>>> - introduced 1-2 years ago, use case was to get all existing >>>> mappings >>>> - with this it's currently possible to replace mapping completely >>>> with new logic >>>> - maybe add a support to "contribute" additional mappings via a >>>> service interface additional to this >>>> >>>> - generic externalizer API >>>> - naming not fixed yet, should not named "link" as this is too >>>> specific. probably "URL". >>>> - needs a java API for using, and an SPI for hooking in special >>>> rules >>>> - then add mappings for views in HTL*, JSP, model exporter/JSON >>>> * probably starting with a sling-only HTL extension for try-out, >>>> add it later to the spec when design is validated >>>> - might be inspired by the basic features for wcm.io URL handler >>>> [1] >>>> >>>> - rewriter pipeline >>>> - should be deprecated and no longer be used - especially not for >>>> link externalization via postprocessing >>>> - it may still be in use out there for more exotic use cases like >>>> PDF generation >>>> - should probably removed from sling starter >>>> >>>> stefan >>>> >>>> [1] https://wcm.io/handler/url/ >>>> >>>> >>>> >>
