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