[
https://issues.apache.org/jira/browse/SLING-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16563273#comment-16563273
]
Julian Sedding commented on SLING-7792:
---------------------------------------
I think providing this information is valuable. I'm reluctant to just add it to
{{ResourceResolver}}, however. It doesn't seem like a method that would get
used a lot. Maybe we could introduce a {{Mapper}} interface (better names
welcome!), which can provide detailed information about mappings and
resolutions. The methods {{ResourceResolver#map}} and
{{ResourceResolver#resolve}} would then become mere convenience methods, but
the canonical source of truth for mappings would be the {{Mapper}}.
Background: for quite some time I have come to the conclusion that the
{{ResourceResolver}} conflates two responsibilities:
- accessing the {{Resource}} tree
- mapping/resolving URLs to/from the {{Resource}} tree
The current implementation shows that these ideas are conflated, which IMHO is
why the mapping/resolution code is not very modular. In an ideal future, we
could get to a point where mapping/resolution is pluggable (via OSGi services)
and the current implementations (i.e. /etc/maps, sling:alias,
sling:vanityPaths) are hooked into this extension point. The {{Mapper}} would
be the service that provides a compound view of all applied
mappings/resolutions.
> Resource Resolver should return more than one resolved path if available
> ------------------------------------------------------------------------
>
> Key: SLING-7792
> URL: https://issues.apache.org/jira/browse/SLING-7792
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.6.0
> Reporter: Alex COLLIGNON
> Priority: Major
>
> The current {{ResourceResolver#map}} methods return a single "path mapped
> from the (resource) path". However, it is possible than a given path can be
> mapped to multiple others while using features such as {{sling:alias}} and
> {{sling:vanityUrl}}.
> In order to support that scenario, it is require to implement new maps method
> for {{ResourceResolver}} which returns a collection of "resolved path". This
> collection must contain the resources mapped through {{/etc/map}},
> {{sling:alias}} and {{sling:vanityUrl}}.
> The current API suggests to implement a second method to be
> consistent/symmetric with the existing map operations
> {quote}
> @Nonnull java.util.Collection<java.lang.String> maps(@Nonnull
> java.lang.String resourcePath)
> @Nonnull java.util.Collection<java.lang.String> maps(@Nonnull
> javax.servlet.http.HttpServletRequest request, @Nonnull java.lang.String
> resourcePath)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
