You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "info@gg-soft.de" <in...@gg-soft.de> on 2009/09/13 20:36:23 UTC
Virtually reusing a node at several locations with mapping links
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
Re: Virtually reusing a node at several locations with mapping links
Posted by Jonathan Cook <jo...@gmail.com>.
Looking at the source of ResourceResolver in current Sling trunk:
for (MapEntry mapEntry : resourceMapper.getMapMaps()) {
String[] mappedPaths = mapEntry.replace(mappedPath);
if (mappedPaths != null) {
....
break;
}
}
confirms that the first matching mapping entry is used as you observe.
If you look at the MapEntry class used there, you'll see that it does
not work according to the heirarchy of how things are defined in
/etc/map but according to the complete URL pattern. The first matching
entry will be used.
When you originally posted about the problem, it was when you cross from
content multi 1 to multi 2 that the problem shows up. Definitely leads
me to see that what you're looking for is for the resolver/mapper to
understand the intention of the transformations in the map and the
relationship between the content. It really isn't that smart,
unfortunately. It does not understand that the content is correlated
as being on the same level, or the pattern that we see when we see a
numbered progression (set membership?).
When I do work on apps this is what I would call the "Application
Context" where sling is only working in a request context.
I think your solution with LinkRewriter or anything else where you write
the logic to correlate multi1 and multi2 are the best solutions. I also
still think that whatever alias/reference methods are available at the
sling level are worth looking into as is the suggestion that someone
else made to use relative paths. Then you would be expressing the
relationships directly (explicitly and implicitly respectively).
Hope this helps,
Jonathan 'J5' Cook
info@gg-soft.de wrote:
> Hi Jonathan,
>
> you are right about the mapping. In fact I do use /etc/map root level mappings like a many-to-one mapping.
> E.g. similar to:
>
> /etc/map/
> |--/http
> |--|--/any_host
> |--|--|--/group1_multi
> |--|--|--|--.sling:internalRedirect=/multi
> |--|--|--/group2_multi
> |--|--|--|--.sling:internalRedirect=/multi
>
> The resolving works quite as you would expect. A request http://any_host/group2_multi gets correctly resolved to /multi node.
>
> Response-rewriting also gets applied. Sling automatically uses the deepest root level mapping rule available. Two rules apply here to /multi, but they are on the same level. And in this case, Sling seems to choose just the first. So my request to http://any_host/group2_multi gets resolved to /multi, but the rewriting of links to /multi node on this page will be done to http://any_host/group1_multi.
>
> The optimal solution (for my use case) would be: If there are multiple deepest root level mappings for a resource, choose the one which was used for resolving the request, not just simply the first one.
>
> BTW: I also use CQ5, not just plain Sling ;-) But the behaviour and problem is quite the same.
>
> Regards,
>
> Matthias
>
>
>
> Jonathan Cook <jo...@gmail.com> hat am 14. September 2009 um 18:14 geschrieben:
>
>
>> It looks like you are trying to reverse a many-to-one mapping.
>>
>> Let's simplify this even further
>>
>> Inbound Transformation:
>> a/1 -> x/1
>> b/1 -> x/1
>>
>> Desired Outbound Transformation:
>> x/1 -> a/1
>> x/1 -> b/1
>>
>> This clarifies the domain of the problem, which is the behavior of the
>> outbound transformation, which is implemented in ResourceResolver.map()
>>
>> You may be confusing the problem when you refer to x/1 as being a/1 --
>> it's not. As soon as the inbound resolution takes place, it becomes
>> x/1. The operations of the code attached to x/1 happen on x/1.
>>
>> Taking a step back to the desired outcome rather than the specific
>> behavior that you don't want, namely that a/1 behave as if it were x/1,
>> I would guess that the aliasing functionality is more appropriate as a
>> solution to your problem than the ResourceResolver/mapping system.
>>
>> You need to actually have a node at a/1 (your /group1/multi1) and that
>> node needs to be a reference to x/1 (your /multi/multi1) for the
>> "mapping" to work as desired.
>>
>> If you want to go back to looking at the ResourceResolver.map and trying
>> to see how it could do the many-to-one mapping, you must introduce
>> another variable so that you are in fact reversing a more complex
>> one-to-one mapping. For instance, taking into account the original path
>> or other members of the request object. That path (or other value) must
>> then either be explicitly sent with the map call (essentially what you
>> are doing with your custom LinkRewriter, I'd wager) or be derivable.
>>
>> From what I understand about the algorithm used by the new
>> ResourceResolver, it will attempt to derive the path from the
>> originating request when a map is performed, but will not be able to
>> when the original inbound transformation is done via a regular
>> expression. It attempts to derive the path value that lets it turn the
>> many-to-one mapping into a one-to-one mapping that can be reversed.
>>
>> Remove use of regex from your inbound mappings and you may find that you
>> already have functioning outbound mappings. In that case, if the output
>> you get is not what is desired, try calling the ResourceResolver.map
>> method explicitly. I don't work with raw SLING (only with Day CQ as of
>> yet) so I don't know whether there IS any automatic remapping of URLs
>> done in the vanilla SLING.
>>
>> Regards,
>> Jonathan 'J5' Cook
>>
>> P.S. I hate to advertise but I am a
>> Day/Javascript/Java/anything-you-throw-at-me
>> developer/architect/handyman looking for telecommute work or work in the
>> Northern Virginia / Washington DC area. If you can help or are
>> interested in discussing a position with me, please don't hesitate to
>> contact me via email or GTalk.
>>
>> Markus Pallo wrote:
>>
>>> We have a similar use case and still not solved yet ....
>>>
>>> During searching i found
>>>
>>> https://issues.apache.org/jira/browse/SLING-598 and thought probably
>>> it could be helpful to use some url like
>>>
>>> http://host/group1/uuid-{uuid ofmulti_content1}
>>>
>>> and to resolve path to parent manually if its a child of my "multi".
>>>
>>>
>>> what do you think ?
>>>
>>>
>>>
>>> Markus
>>>
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>
>
Re: Virtually reusing a node at several locations with mapping links
Posted by Jonathan Cook <jo...@gmail.com>.
Matthias,
The problem there is with any_host node, you're doing a regex match
there, right? My guess would be that without that sling:match regex
that the reverse mapping would work as desired.
Can you specify the hosts? Even if it is a cumbersome process, you can
always script it.
Regards,
Jonathan 'J5' Cook
info@gg-soft.de wrote:
> Hi Jonathan,
>
> you are right about the mapping. In fact I do use /etc/map root level mappings like a many-to-one mapping.
> E.g. similar to:
>
> /etc/map/
> |--/http
> |--|--/any_host
> |--|--|--/group1_multi
> |--|--|--|--.sling:internalRedirect=/multi
> |--|--|--/group2_multi
> |--|--|--|--.sling:internalRedirect=/multi
>
> The resolving works quite as you would expect. A request http://any_host/group2_multi gets correctly resolved to /multi node.
>
> Response-rewriting also gets applied. Sling automatically uses the deepest root level mapping rule available. Two rules apply here to /multi, but they are on the same level. And in this case, Sling seems to choose just the first. So my request to http://any_host/group2_multi gets resolved to /multi, but the rewriting of links to /multi node on this page will be done to http://any_host/group1_multi.
>
> The optimal solution (for my use case) would be: If there are multiple deepest root level mappings for a resource, choose the one which was used for resolving the request, not just simply the first one.
>
> BTW: I also use CQ5, not just plain Sling ;-) But the behaviour and problem is quite the same.
>
> Regards,
>
> Matthias
>
>
>
> Jonathan Cook <jo...@gmail.com> hat am 14. September 2009 um 18:14 geschrieben:
>
>
>> It looks like you are trying to reverse a many-to-one mapping.
>>
>> Let's simplify this even further
>>
>> Inbound Transformation:
>> a/1 -> x/1
>> b/1 -> x/1
>>
>> Desired Outbound Transformation:
>> x/1 -> a/1
>> x/1 -> b/1
>>
>> This clarifies the domain of the problem, which is the behavior of the
>> outbound transformation, which is implemented in ResourceResolver.map()
>>
>> You may be confusing the problem when you refer to x/1 as being a/1 --
>> it's not. As soon as the inbound resolution takes place, it becomes
>> x/1. The operations of the code attached to x/1 happen on x/1.
>>
>> Taking a step back to the desired outcome rather than the specific
>> behavior that you don't want, namely that a/1 behave as if it were x/1,
>> I would guess that the aliasing functionality is more appropriate as a
>> solution to your problem than the ResourceResolver/mapping system.
>>
>> You need to actually have a node at a/1 (your /group1/multi1) and that
>> node needs to be a reference to x/1 (your /multi/multi1) for the
>> "mapping" to work as desired.
>>
>> If you want to go back to looking at the ResourceResolver.map and trying
>> to see how it could do the many-to-one mapping, you must introduce
>> another variable so that you are in fact reversing a more complex
>> one-to-one mapping. For instance, taking into account the original path
>> or other members of the request object. That path (or other value) must
>> then either be explicitly sent with the map call (essentially what you
>> are doing with your custom LinkRewriter, I'd wager) or be derivable.
>>
>> From what I understand about the algorithm used by the new
>> ResourceResolver, it will attempt to derive the path from the
>> originating request when a map is performed, but will not be able to
>> when the original inbound transformation is done via a regular
>> expression. It attempts to derive the path value that lets it turn the
>> many-to-one mapping into a one-to-one mapping that can be reversed.
>>
>> Remove use of regex from your inbound mappings and you may find that you
>> already have functioning outbound mappings. In that case, if the output
>> you get is not what is desired, try calling the ResourceResolver.map
>> method explicitly. I don't work with raw SLING (only with Day CQ as of
>> yet) so I don't know whether there IS any automatic remapping of URLs
>> done in the vanilla SLING.
>>
>> Regards,
>> Jonathan 'J5' Cook
>>
>> P.S. I hate to advertise but I am a
>> Day/Javascript/Java/anything-you-throw-at-me
>> developer/architect/handyman looking for telecommute work or work in the
>> Northern Virginia / Washington DC area. If you can help or are
>> interested in discussing a position with me, please don't hesitate to
>> contact me via email or GTalk.
>>
>> Markus Pallo wrote:
>>
>>> We have a similar use case and still not solved yet ....
>>>
>>> During searching i found
>>>
>>> https://issues.apache.org/jira/browse/SLING-598 and thought probably
>>> it could be helpful to use some url like
>>>
>>> http://host/group1/uuid-{uuid ofmulti_content1}
>>>
>>> and to resolve path to parent manually if its a child of my "multi".
>>>
>>>
>>> what do you think ?
>>>
>>>
>>>
>>> Markus
>>>
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>
>
Re: Virtually reusing a node at several locations with mapping
links
Posted by "info@gg-soft.de" <in...@gg-soft.de>.
Hi Jonathan,
you are right about the mapping. In fact I do use /etc/map root level mappings like a many-to-one mapping.
E.g. similar to:
/etc/map/
|--/http
|--|--/any_host
|--|--|--/group1_multi
|--|--|--|--.sling:internalRedirect=/multi
|--|--|--/group2_multi
|--|--|--|--.sling:internalRedirect=/multi
The resolving works quite as you would expect. A request http://any_host/group2_multi gets correctly resolved to /multi node.
Response-rewriting also gets applied. Sling automatically uses the deepest root level mapping rule available. Two rules apply here to /multi, but they are on the same level. And in this case, Sling seems to choose just the first. So my request to http://any_host/group2_multi gets resolved to /multi, but the rewriting of links to /multi node on this page will be done to http://any_host/group1_multi.
The optimal solution (for my use case) would be: If there are multiple deepest root level mappings for a resource, choose the one which was used for resolving the request, not just simply the first one.
BTW: I also use CQ5, not just plain Sling ;-) But the behaviour and problem is quite the same.
Regards,
Matthias
Jonathan Cook <jo...@gmail.com> hat am 14. September 2009 um 18:14 geschrieben:
> It looks like you are trying to reverse a many-to-one mapping.
>
> Let's simplify this even further
>
> Inbound Transformation:
> a/1 -> x/1
> b/1 -> x/1
>
> Desired Outbound Transformation:
> x/1 -> a/1
> x/1 -> b/1
>
> This clarifies the domain of the problem, which is the behavior of the
> outbound transformation, which is implemented in ResourceResolver.map()
>
> You may be confusing the problem when you refer to x/1 as being a/1 --
> it's not. As soon as the inbound resolution takes place, it becomes
> x/1. The operations of the code attached to x/1 happen on x/1.
>
> Taking a step back to the desired outcome rather than the specific
> behavior that you don't want, namely that a/1 behave as if it were x/1,
> I would guess that the aliasing functionality is more appropriate as a
> solution to your problem than the ResourceResolver/mapping system.
>
> You need to actually have a node at a/1 (your /group1/multi1) and that
> node needs to be a reference to x/1 (your /multi/multi1) for the
> "mapping" to work as desired.
>
> If you want to go back to looking at the ResourceResolver.map and trying
> to see how it could do the many-to-one mapping, you must introduce
> another variable so that you are in fact reversing a more complex
> one-to-one mapping. For instance, taking into account the original path
> or other members of the request object. That path (or other value) must
> then either be explicitly sent with the map call (essentially what you
> are doing with your custom LinkRewriter, I'd wager) or be derivable.
>
> From what I understand about the algorithm used by the new
> ResourceResolver, it will attempt to derive the path from the
> originating request when a map is performed, but will not be able to
> when the original inbound transformation is done via a regular
> expression. It attempts to derive the path value that lets it turn the
> many-to-one mapping into a one-to-one mapping that can be reversed.
>
> Remove use of regex from your inbound mappings and you may find that you
> already have functioning outbound mappings. In that case, if the output
> you get is not what is desired, try calling the ResourceResolver.map
> method explicitly. I don't work with raw SLING (only with Day CQ as of
> yet) so I don't know whether there IS any automatic remapping of URLs
> done in the vanilla SLING.
>
> Regards,
> Jonathan 'J5' Cook
>
> P.S. I hate to advertise but I am a
> Day/Javascript/Java/anything-you-throw-at-me
> developer/architect/handyman looking for telecommute work or work in the
> Northern Virginia / Washington DC area. If you can help or are
> interested in discussing a position with me, please don't hesitate to
> contact me via email or GTalk.
>
> Markus Pallo wrote:
> > We have a similar use case and still not solved yet ....
> >
> > During searching i found
> >
> > https://issues.apache.org/jira/browse/SLING-598 and thought probably
> > it could be helpful to use some url like
> >
> > http://host/group1/uuid-{uuid ofmulti_content1}
> >
> > and to resolve path to parent manually if its a child of my "multi".
> >
> >
> > what do you think ?
> >
> >
> >
> > Markus
> >
> >
> >> 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
> >>
> >>
> >
>
Re: Virtually reusing a node at several locations with mapping links
Posted by Jonathan Cook <jo...@gmail.com>.
It looks like you are trying to reverse a many-to-one mapping.
Let's simplify this even further
Inbound Transformation:
a/1 -> x/1
b/1 -> x/1
Desired Outbound Transformation:
x/1 -> a/1
x/1 -> b/1
This clarifies the domain of the problem, which is the behavior of the
outbound transformation, which is implemented in ResourceResolver.map()
You may be confusing the problem when you refer to x/1 as being a/1 --
it's not. As soon as the inbound resolution takes place, it becomes
x/1. The operations of the code attached to x/1 happen on x/1.
Taking a step back to the desired outcome rather than the specific
behavior that you don't want, namely that a/1 behave as if it were x/1,
I would guess that the aliasing functionality is more appropriate as a
solution to your problem than the ResourceResolver/mapping system.
You need to actually have a node at a/1 (your /group1/multi1) and that
node needs to be a reference to x/1 (your /multi/multi1) for the
"mapping" to work as desired.
If you want to go back to looking at the ResourceResolver.map and trying
to see how it could do the many-to-one mapping, you must introduce
another variable so that you are in fact reversing a more complex
one-to-one mapping. For instance, taking into account the original path
or other members of the request object. That path (or other value) must
then either be explicitly sent with the map call (essentially what you
are doing with your custom LinkRewriter, I'd wager) or be derivable.
From what I understand about the algorithm used by the new
ResourceResolver, it will attempt to derive the path from the
originating request when a map is performed, but will not be able to
when the original inbound transformation is done via a regular
expression. It attempts to derive the path value that lets it turn the
many-to-one mapping into a one-to-one mapping that can be reversed.
Remove use of regex from your inbound mappings and you may find that you
already have functioning outbound mappings. In that case, if the output
you get is not what is desired, try calling the ResourceResolver.map
method explicitly. I don't work with raw SLING (only with Day CQ as of
yet) so I don't know whether there IS any automatic remapping of URLs
done in the vanilla SLING.
Regards,
Jonathan 'J5' Cook
P.S. I hate to advertise but I am a
Day/Javascript/Java/anything-you-throw-at-me
developer/architect/handyman looking for telecommute work or work in the
Northern Virginia / Washington DC area. If you can help or are
interested in discussing a position with me, please don't hesitate to
contact me via email or GTalk.
Markus Pallo wrote:
> We have a similar use case and still not solved yet ....
>
> During searching i found
>
> https://issues.apache.org/jira/browse/SLING-598 and thought probably
> it could be helpful to use some url like
>
> http://host/group1/uuid-{uuid ofmulti_content1}
>
> and to resolve path to parent manually if its a child of my "multi".
>
>
> what do you think ?
>
>
>
> Markus
>
>
>> 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
>>
>>
>
Re: Virtually reusing a node at several locations with mapping links
Posted by Markus Pallo <pa...@dig.de>.
We have a similar use case and still not solved yet ....
During searching i found
https://issues.apache.org/jira/browse/SLING-598 and thought probably it
could be helpful to use some url like
http://host/group1/uuid-{uuid ofmulti_content1}
and to resolve path to parent manually if its a child of my "multi".
what do you think ?
Markus
> 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
>
>
--
------------------------------------------------------------------
DIG Digitale Medienberatungs-
und Produktions- GmbH
Neckarstr. 1/5
78727 Oberndorf a. N.
Amtsgericht Stuttgart HRB 480914
Geschäftsführer: Carsten Huber
------------------------------------------------------------------
Tel: +49 (0)7423 8750 60
Fax: +49 (0)7423 8750 23
Internet: http://www.dig.de
eMail: pallo@dig.de
Ein Unternehmen der Schwarzwälder Bote Mediengruppe
Re: Virtually reusing a node at several locations with mapping links
Posted by Ian Boston <ie...@tfd.co.uk>.
Sent from my iPhone
On 14 Sep 2009, at 08:18, "info@gg-soft.de" <in...@gg-soft.de> 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,
>
> Matthias
>
>
> Ian Boston <ie...@tfd.co.uk> hat am 13. September 2009 um 23:56
> geschrieben:
>
>> 2009/9/14 info@gg-soft.de <in...@gg-soft.de>:
>>> 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 <ie...@tfd.co.uk> hat am 13. September 2009 um 21:45
>>> geschrieben:
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 14 Sep 2009, at 04:36, "info@gg-soft.de" <in...@gg-soft.de>
>>>> 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
>>>>>
>>>
Re: Virtually reusing a node at several locations with mapping
links
Posted by "info@gg-soft.de" <in...@gg-soft.de>.
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 <ie...@tfd.co.uk> hat am 13. September 2009 um 23:56 geschrieben:
> 2009/9/14 info@gg-soft.de <in...@gg-soft.de>:
> > 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 <ie...@tfd.co.uk> hat am 13. September 2009 um 21:45 geschrieben:
> >
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On 14 Sep 2009, at 04:36, "info@gg-soft.de" <in...@gg-soft.de> 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
> >> >
> >
Re: Virtually reusing a node at several locations with mapping links
Posted by Ian Boston <ie...@tfd.co.uk>.
2009/9/14 info@gg-soft.de <in...@gg-soft.de>:
> 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 <ie...@tfd.co.uk> hat am 13. September 2009 um 21:45 geschrieben:
>
>>
>>
>> Sent from my iPhone
>>
>> On 14 Sep 2009, at 04:36, "info@gg-soft.de" <in...@gg-soft.de> 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
>> >
>
Re: Virtually reusing a node at several locations with mapping
links
Posted by "info@gg-soft.de" <in...@gg-soft.de>.
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 <ie...@tfd.co.uk> hat am 13. September 2009 um 21:45 geschrieben:
>
>
> Sent from my iPhone
>
> On 14 Sep 2009, at 04:36, "info@gg-soft.de" <in...@gg-soft.de> 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
> >
Re: Virtually reusing a node at several locations with mapping links
Posted by Ian Boston <ie...@tfd.co.uk>.
Sent from my iPhone
On 14 Sep 2009, at 04:36, "info@gg-soft.de" <in...@gg-soft.de> 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
>