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/
