Hi Georg, Is the class https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/uri/ResourceURI.java <https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/uri/ResourceURI.java> supposed to be used for both internal as well as for external links? I would rather come up with two separate classes (they don't have much in common).
What about a generic SlingUri class with the two specializations ResourceUri and AbsoluteUri (or ExternalUri)? That you would lead the following signatures in https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java <https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java>: ResourceUri resolve(ResourceURI, ...) (not useful for absolute/external URIs) SlingUri map(SlingUri, ...) (can be useful even to map an external URI) I definitely prefer immutable classes with a dedicated builder but that is up for another discussion I guess, Konrad > On 30. Mar 2020, at 02:13, Georg Henzler <ghenz...@apache.org> wrote: > > 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/
