It looks like you are trying to reverse a many-to-one mapping.
Let's simplify this even further
Inbound Transformation:
a/1 -> x/1
b/1 -> x/1
Desired Outbound Transformation:
x/1 -> a/1
x/1 -> b/1
This clarifies the domain of the problem, which is the behavior of the
outbound transformation, which is implemented in ResourceResolver.map()
You may be confusing the problem when you refer to x/1 as being a/1 --
it's not. As soon as the inbound resolution takes place, it becomes
x/1. The operations of the code attached to x/1 happen on x/1.
Taking a step back to the desired outcome rather than the specific
behavior that you don't want, namely that a/1 behave as if it were x/1,
I would guess that the aliasing functionality is more appropriate as a
solution to your problem than the ResourceResolver/mapping system.
You need to actually have a node at a/1 (your /group1/multi1) and that
node needs to be a reference to x/1 (your /multi/multi1) for the
"mapping" to work as desired.
If you want to go back to looking at the ResourceResolver.map and trying
to see how it could do the many-to-one mapping, you must introduce
another variable so that you are in fact reversing a more complex
one-to-one mapping. For instance, taking into account the original path
or other members of the request object. That path (or other value) must
then either be explicitly sent with the map call (essentially what you
are doing with your custom LinkRewriter, I'd wager) or be derivable.
From what I understand about the algorithm used by the new
ResourceResolver, it will attempt to derive the path from the
originating request when a map is performed, but will not be able to
when the original inbound transformation is done via a regular
expression. It attempts to derive the path value that lets it turn the
many-to-one mapping into a one-to-one mapping that can be reversed.
Remove use of regex from your inbound mappings and you may find that you
already have functioning outbound mappings. In that case, if the output
you get is not what is desired, try calling the ResourceResolver.map
method explicitly. I don't work with raw SLING (only with Day CQ as of
yet) so I don't know whether there IS any automatic remapping of URLs
done in the vanilla SLING.
Regards,
Jonathan 'J5' Cook
P.S. I hate to advertise but I am a
Day/Javascript/Java/anything-you-throw-at-me
developer/architect/handyman looking for telecommute work or work in the
Northern Virginia / Washington DC area. If you can help or are
interested in discussing a position with me, please don't hesitate to
contact me via email or GTalk.
Markus Pallo wrote:
We have a similar use case and still not solved yet ....
During searching i found
https://issues.apache.org/jira/browse/SLING-598 and thought probably
it could be helpful to use some url like
http://host/group1/uuid-{uuid ofmulti_content1}
and to resolve path to parent manually if its a child of my "multi".
what do you think ?
Markus
I currently have a use case for Sling rewriting, but still found no
"out-of-the-box" solution in the Sling flexible resource resolution
for it.
My application has a requirement for a node which should be virtually
duplicated. The example node structure is like this:
/group1
/group2
/multi
|--/multi_content1
|--/multi_content2
"Multi" should be available for each group individually. The content
stays the same, but it acts differently in each group depending on
the JCR-path or URI. To avoid problems with double-namings in the
"real" group-content and in the "multi" group-content, I decided to
use a seperate node for each multi-group with suffix "_multi".
So the structure should look virtually like this:
/group1
/group1_multi
|--/multi_content1
|--/multi_content2
/group2
/group2_multi
|--/multi_content1
|--/multi_content2
/multi
|--/multi_content1
|--/multi_content2
The goal is to handle requests like this with the same content (but
different path / URI):
/group1_multi/multi_content_1 --> /multi/multi_content1
/group2_multi/multi_content_1 --> /multi/multi_content1
