Sent from my iPhone On 14 Sep 2009, at 08:18, "[email protected]" <[email protected]> wrote:
OK sorry I didn't get your question right.I already have a "docroot" where global elements like images, CSS etc. are stored. The reason why I need different "virtual nodes" for the same content is in the behaviour of the content (=pages) itself. Although it is the same, it needs to act differently depending on where it is located. Or: virtually located. ;-)
Ahh ok that makes sense, sounds like it needs the rewritten resource to have access to the orriginal URL rather than the remapped resource?
I will re read the thread and if I think of anything I will get back to you.
Ian
To stick with the given example:Think of some kind of top-level navigation which shows in which group (group1,group2) you are. When you switch to the multi-content, you would lose this information if you just follow the link to / multi/multi_content1. The navigation on multi_content1 page would not be able to display wheter you are currently in group1 or group2. But logically all this content of multi-group resides in each of the groups, so it should display this information. To the browser, it should all the time look like if there is no top- level group called "/multi"I implemented the already mentioned solution (regexp in /etc/map together with custom link-rewriting) now, and it works quite good so far. But it would still be a better solution to use some features of Sling resource resolving, if possible.Thanks for your advice, MatthiasIan Boston <[email protected]> hat am 13. September 2009 um 23:56 geschrieben:2009/9/14 [email protected] <[email protected]>:Hi Ian,yes: the "multi"-structure is very big (> 1gb), and I have about 7 groups; so instead 1gb for a re-used structure, I would have 8gb (1 master + 7 copies) of content. As this problem applies for 4 different structures, the content would even increase to 4 * 8 = 32gb instead of just 4 * 1 = 4gb. I already wrote a "replicate-content-silently" - PageModification - listener, but this solution just produces too much content in my opinion.I wasn't advocating copying the data as that would, as you point out, be a waste. I was asking if the internal links within the content could be *relative*, avoiding the need to re-write the internal URL's ? But, perhaps I a misunderstanding the requirement. I am assuming that the links you need to rewrite are <html/<img/<link etc links within html/css/js in the browser and not something that needs to be resolved internally within Sling. IanGreetings, MatthiasIan Boston <[email protected]> hat am 13. September 2009 um 21:45 geschrieben:Sent from my iPhoneOn 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 resolutionfor 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 contentstays 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 touse 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_content2The goal is to handle requests like this with the same content (butdifferent 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 anotherpage 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/mapentry per "/groupX_multi" mapping would be perfect, but because they all redirect to the same node, the root level mapping of Sling willalways 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 clarificationIs there a reason you can't make the subtree in each location the same structure and so that relative links between different subtrees wouldwork regardless of where they were? IanThanks in advance. Regards, Matthias Wermund
