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. ;-)
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, Matthias Ian 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. > > Ian > > > > > > > Greetings, > > > > Matthias > > > > > > Ian Boston <[email protected]> hat am 13. September 2009 um 21:45 geschrieben: > > > >> > >> > >> 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 > >> > > >
