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 > >> > >> > > >
