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