Sent from my iPhone
On 14 Sep 2009, at 04:36, "[email protected]" <[email protected]> wrote:
Hi Sling developers,
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
The important point in this is that if the user moves to another
page in this "multi" group, the context should stay. In other words,
the links in the multi_contentX page must be rewritten to use the
groupX_multi parent.
Example:
If the first request is/group1_multi/multi_content1 (resolved to /
multi/multi_content1),
all links on this page which are to other "multi" pages should be /
group1_multi/... instead of /multi/...
I see several working approaches for the initial resource resolving,
but when you enter the page, I see no way to rewrite the links
according to the resource resolution that took place. One /etc/map
entry per "/groupX_multi" mapping would be perfect, but because they
all redirect to the same node, the root level mapping of Sling will
always choose the first entryfor rewritingand not the one that
actually was part of the request.
A possible solution that should work but would require some custom
implementation could be:
1. Create a /etc/map root level mapping, with a regular expression
which catches all requests to "/groupX_multi" and do a
sling:internalRedirect to /multi (so far, so good)
2. As no rewriting of links happens because of the RegExp, rewrite
all links in the Rewriter-Pipeline based on the used URI in the
request.
Step 1 is good and very intuitive, but step 2 is very ugly. Do you
know another way?
For clarification
Is there a reason you can't make the subtree in each location the same
structure and so that relative links between different subtrees would
work regardless of where they were?
Ian
Thanks in advance.
Regards,
Matthias Wermund
