Hi Konrad,
yes, ResourceURI at the moment would be both for internal and external
links.
Immutable vs. Mutable is to be discussed (both ways have their own
advantages)
ResourceUri resolve(ResourceURI, ...) (not useful for absolute/external
URIs)
SlingUri map(SlingUri, ...) (can be useful even to map an external URI)
Because it is meant to be a pipeline of OSGi services in a row of which
any
could make the decision to switch from a plain path to a full URI IMHO
we need
to pass an interface that covers both. This approach could mean (names
are
more descriptive than a real suggestion for now):
interface ResourceUri extends ArbitraryLink {...}
interface ResourcePath extends ArbitraryLink {...} #
RequestPathInfo+query+fragment
The ResourceMapping interface would then look symmetric again:
ArbitraryLink resolve(ArbitraryLink, ...)
ArbitraryLink map(ArbitraryLink, ...)
-Georg
On 2020-03-30 21:17, Konrad Windszus wrote:
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>:
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/
