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?


Thanks in advance.

Regards,

Matthias Wermund

Reply via email to