sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Windszus <konra...@gmx.de>
Subject Re: [DISCUSS] Resource Mapping SPI
Date Mon, 30 Mar 2020 19:17:21 GMT
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 <ghenzler@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 <konrad_w@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.bailey@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/


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message