Matthias,
The problem there is with any_host node, you're doing a regex match
there, right? My guess would be that without that sling:match regex
that the reverse mapping would work as desired.
Can you specify the hosts? Even if it is a cumbersome process, you can
always script it.
Regards,
Jonathan 'J5' Cook
[email protected] wrote:
Hi Jonathan,
you are right about the mapping. In fact I do use /etc/map root level mappings
like a many-to-one mapping.
E.g. similar to:
/etc/map/
|--/http
|--|--/any_host
|--|--|--/group1_multi
|--|--|--|--.sling:internalRedirect=/multi
|--|--|--/group2_multi
|--|--|--|--.sling:internalRedirect=/multi
The resolving works quite as you would expect. A request
http://any_host/group2_multi gets correctly resolved to /multi node.
Response-rewriting also gets applied. Sling automatically uses the deepest root
level mapping rule available. Two rules apply here to /multi, but they are on
the same level. And in this case, Sling seems to choose just the first. So my
request to http://any_host/group2_multi gets resolved to /multi, but the
rewriting of links to /multi node on this page will be done to
http://any_host/group1_multi.
The optimal solution (for my use case) would be: If there are multiple deepest
root level mappings for a resource, choose the one which was used for resolving
the request, not just simply the first one.
BTW: I also use CQ5, not just plain Sling ;-) But the behaviour and problem is
quite the same.
Regards,
Matthias
Jonathan Cook <[email protected]> hat am 14. September 2009 um 18:14
geschrieben:
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
