You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Alec Bickerton <al...@minick.ch> on 2008/02/27 14:02:33 UTC
Sitemap pipelines
Hi,
I'm looking to streamline the sitemap that is being used and am seeing a
few problems.
First, a little bit of background...
The application has evolved over a time to contain a large number of
subdirectories. These subdirectories are not self contained and for the
most part rely on the pipeline in the root sitemap. The upshot being
that the root sitemap contains a considerable amount of project specific
matchers
As far as I can see, It I use the following ,Then the pipeline in the
sitemap in the customer1 directory will be entered.
<map:match pattern="customer1/**"/>
<map:mount uri-prefix="customer1" src="customer1/sitemap.xmap"
check-reload="yes" reload-method="asynchron"/>
</map:match>
This is almost what I need, however, I need the pipeline to return to
the pipeline in the global sitemap if nothing matches so that the
default matchers will get hit.
An example customer sitemap would look like.
<?xml version="1.0"?>
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:pipelines>
<map:pipeline>
<map:match pattern="*/**">
<map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
so for example.
for the request
mysite.com/cocoon/projects/customer1/project2/index.html
the pipeline needs to go:
1: sitemap in cocoon directory
2: sitemap in projects directory
3: sitemap in customer1 directory
4: sitemap in projects2 directory matches *.html and performs an action
does not redirect as the user is allowed.
5: returns to the sitemap in customer1 directory at the point in the
pipline where mount was called
6: returns to the pipeline in the sitemap in projects directory where
the *.ml matcher is declared after the customer matchers.
Can anyone suggest the best means for me to accomplish this?
Thanks,
Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.02.2008 08:02, Alec Bickerton wrote:
> As far as I can see, It I use the following ,Then the pipeline in the
> sitemap in the customer1 directory will be entered.
>
> <map:match pattern="customer1/**"/>
> <map:mount uri-prefix="customer1" src="customer1/sitemap.xmap"
> check-reload="yes" reload-method="asynchron"/>
> </map:match>
>
> This is almost what I need, however, I need the pipeline to return to
> the pipeline in the global sitemap if nothing matches so that the
> default matchers will get hit.
>
> An example customer sitemap would look like.
>
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <map:pipelines>
> <map:pipeline>
> <map:match pattern="*/**">
> <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
> </map:match>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
>
> so for example.
>
> for the request
> mysite.com/cocoon/projects/customer1/project2/index.html
>
> the pipeline needs to go:
> 1: sitemap in cocoon directory
> 2: sitemap in projects directory
> 3: sitemap in customer1 directory
> 4: sitemap in projects2 directory matches *.html and performs an action
> does not redirect as the user is allowed.
> 5: returns to the sitemap in customer1 directory at the point in the
> pipline where mount was called
> 6: returns to the pipeline in the sitemap in projects directory where
> the *.ml matcher is declared after the customer matchers.
>
> Can anyone suggest the best means for me to accomplish this?
It seems I can't see the problem. Doesn't the above generic matcher do
exactly what you want?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Alec Bickerton <al...@minick.ch>.
Dev at weitling wrote:
>
>
> Grzegorz Kossakowski wrote:
>> Joerg Heinicke wrote:
>>
>>> On 10.03.2008 18:48, Grzegorz Kossakowski wrote:
>>>
>>>
>>>>> That's what I originally tried. It would seem that due to a matcher in
>>>>> the sub sitemap that matches all html requests. This matcher
>>>>> contains a
>>>>> simple action to verify a request header and redirect if not present.
>>>>>
>>>>> Once the action is called without having to redirect, control is not
>>>>> returned to the parent.
>>>>>
>>>>> I originally tried adding a redirect to cocoon://default/ and that
>>>>> didn't help. When there is a lot of nested sitemaps I can see that
>>>>> approach becoming evil. ;-)
>>>>>
>>>> What about magic "pass-through" attribute of map:mount?
>>>>
>>> So you actually have to configure that it falls back to the parent
>>> sitemap? Man, I haven't work with Cocoon for too long ;-)
>>>
>> Yep, exactly.
>>
>> I discovered this attribute while removing support for <map:mount> in
>> Micro Cocoon. That was very interesting experience to dive into guts of
>> Cocoon. ;-)
>>
>
> Is it documented somewhere? We don't want to loose this gem!
>
Excellent, this attribute does exactly what I need.
Thanks all.
Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Mar 12, 2008, at 10:45 AM, Steven D. Majewski wrote:
> What is "Micro Cocoon" ?
http://www.mail-archive.com/dev@cocoon.apache.org/msg54977.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by "Steven D. Majewski" <sd...@virginia.edu>.
On Mar 12, 2008, at 1:27 PM, Grzegorz Kossakowski wrote:
> Dev at weitling pisze:
>>
>> Yes, of course. Or will it be lost with Micro Cocoon?
>
>
What is "Micro Cocoon" ?
-- Steve Majewski / UVA Alderman Library
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Dev at weitling pisze:
>
> Yes, of course. Or will it be lost with Micro Cocoon?
It will be lost with Micro Cocoon but there is already a replacement for it: it's polymorphism
concept in SSF which works similarly or at least serves similar function, see:
http://article.gmane.org/gmane.text.xml.cocoon.devel/77006 (sight, this docs must be really
published ASAP)
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Dev at weitling <de...@weitling.net>.
Grzegorz Kossakowski wrote:
> Dev at weitling pisze:
>
>>> Yep, exactly.
>>>
>>> I discovered this attribute while removing support for <map:mount> in
>>> Micro Cocoon. That was very interesting experience to dive into guts of
>>> Cocoon. ;-)
>>>
>>>
>> Is it documented somewhere? We don't want to loose this gem!
>>
>
> Are you referring to pass-through attribute?
>
Yes, of course. Or will it be lost with Micro Cocoon?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Dev at weitling pisze:
>> Yep, exactly.
>>
>> I discovered this attribute while removing support for <map:mount> in
>> Micro Cocoon. That was very interesting experience to dive into guts of
>> Cocoon. ;-)
>>
>
> Is it documented somewhere? We don't want to loose this gem!
Are you referring to pass-through attribute?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Dev at weitling <de...@weitling.net>.
Grzegorz Kossakowski wrote:
> Joerg Heinicke wrote:
>
>> On 10.03.2008 18:48, Grzegorz Kossakowski wrote:
>>
>>
>>>> That's what I originally tried. It would seem that due to a matcher in
>>>> the sub sitemap that matches all html requests. This matcher contains a
>>>> simple action to verify a request header and redirect if not present.
>>>>
>>>> Once the action is called without having to redirect, control is not
>>>> returned to the parent.
>>>>
>>>> I originally tried adding a redirect to cocoon://default/ and that
>>>> didn't help. When there is a lot of nested sitemaps I can see that
>>>> approach becoming evil. ;-)
>>>>
>>> What about magic "pass-through" attribute of map:mount?
>>>
>> So you actually have to configure that it falls back to the parent
>> sitemap? Man, I haven't work with Cocoon for too long ;-)
>>
> Yep, exactly.
>
> I discovered this attribute while removing support for <map:mount> in
> Micro Cocoon. That was very interesting experience to dive into guts of
> Cocoon. ;-)
>
Is it documented somewhere? We don't want to loose this gem!
Bye,
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke wrote:
> On 10.03.2008 18:48, Grzegorz Kossakowski wrote:
>
>>> That's what I originally tried. It would seem that due to a matcher in
>>> the sub sitemap that matches all html requests. This matcher contains a
>>> simple action to verify a request header and redirect if not present.
>>>
>>> Once the action is called without having to redirect, control is not
>>> returned to the parent.
>>>
>>> I originally tried adding a redirect to cocoon://default/ and that
>>> didn't help. When there is a lot of nested sitemaps I can see that
>>> approach becoming evil. ;-)
>>
>> What about magic "pass-through" attribute of map:mount?
>
> So you actually have to configure that it falls back to the parent
> sitemap? Man, I haven't work with Cocoon for too long ;-)
Yep, exactly.
I discovered this attribute while removing support for <map:mount> in
Micro Cocoon. That was very interesting experience to dive into guts of
Cocoon. ;-)
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.03.2008 18:48, Grzegorz Kossakowski wrote:
>> That's what I originally tried. It would seem that due to a matcher in
>> the sub sitemap that matches all html requests. This matcher contains a
>> simple action to verify a request header and redirect if not present.
>>
>> Once the action is called without having to redirect, control is not
>> returned to the parent.
>>
>> I originally tried adding a redirect to cocoon://default/ and that
>> didn't help. When there is a lot of nested sitemaps I can see that
>> approach becoming evil. ;-)
>
> What about magic "pass-through" attribute of map:mount?
So you actually have to configure that it falls back to the parent
sitemap? Man, I haven't work with Cocoon for too long ;-)
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Alec Bickerton pisze:
> That's what I originally tried. It would seem that due to a matcher in
> the sub sitemap that matches all html requests. This matcher contains a
> simple action to verify a request header and redirect if not present.
>
> Once the action is called without having to redirect, control is not
> returned to the parent.
>
> I originally tried adding a redirect to cocoon://default/ and that
> didn't help. When there is a lot of nested sitemaps I can see that
> approach becoming evil. ;-)
What about magic "pass-through" attribute of map:mount?
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Alec Bickerton <al...@minick.ch>.
Joerg Heinicke wrote:
> On 10.03.2008 06:27, Tobia Conforto wrote:
>
>>> I need the pipeline to return to the pipeline in the global sitemap
>>> if nothing matches so that the default matchers will get hit.
>>
>> You need to issue an internal redirect to the parent sitemap.
>
> Why? If nothing matches in the sub sitemap control will go back to
> parent sitemap.
>
That's what I originally tried. It would seem that due to a matcher in
the sub sitemap that matches all html requests. This matcher contains a
simple action to verify a request header and redirect if not present.
Once the action is called without having to redirect, control is not
returned to the parent.
I originally tried adding a redirect to cocoon://default/ and that
didn't help. When there is a lot of nested sitemaps I can see that
approach becoming evil. ;-)
Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.03.2008 06:27, Tobia Conforto wrote:
>> I need the pipeline to return to the pipeline in the global sitemap if
>> nothing matches so that the default matchers will get hit.
>
> You need to issue an internal redirect to the parent sitemap.
Why? If nothing matches in the sub sitemap control will go back to
parent sitemap.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Tobia Conforto <to...@linux.it>.
Alec Bickerton wrote:
> I need the pipeline to return to the pipeline in the global sitemap
> if nothing matches so that the default matchers will get hit.
You need to issue an internal redirect to the parent sitemap.
Assuming "/default" is a (fake) path that in the parent sitemap falls
through to the default matcher, without entering ANY sub-pipeline,
then you can put this at the end of your sub-sitemaps (last item after
all matchers, before closing the last pipeline)
<map:redirect-to uri="cocoon://default"/>
The heart of this is the double-slash cocoon: protocol, that will
redirect internally (without sending a redirect to the browser) to the
root sitemap.
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by so...@apache.org.
I created the DeepestSourceFactory. The code is available at:
http://solprovider.com/lenya/deepestsource
I only spent a couple hours so this is unlikely to be the best
possible implementation . The final examples on the webpage could be
part of what your solution.
solprovider
On 3/4/08, Alec Bickerton <al...@minick.ch> wrote:
> Thanks for the pointer, I go and chew it over for a while and see what I
> can come up with.
> Alec
>
> solprovider@apache.org wrote:
> > Cocoon has several methods to pass control between XMAPs. The best is
> > map:mount because it allows non-standard protocols. (We use
> > file-level fallback to discover the next XMAP so map:mount is useful
> > because we can specify the fallback protocol. This is difficult with
> > the cocoon: protocol mentioned next as fallback must be programmed
> > into XMAPs in addition to a SourceFactory.)
> >
> > The basic method of passing control back to the root sitemap is to use
> > a generator with the cocoon: protocol.
> > <map:generate src="cocoon://yourPattern"/>
> > <map:serialize type="xml"/>
> > This is likely what you want. Note the double-slash:
> > cocoon:/patternInCurrentXMAP
> > cocoon://patternInRootXMAP
> >
> > I dislike Actions because standard features are disabled (e.g. no
> > redirects or reads) and variables are misplaced ({1} must be changed
> > to {../1}). Selectors often have similar functionality without the
> > side-effects.
> >
> > Assuming your functionality is simple and most of the XMAPs contain
> > similar functionality, you might condense your XMAPs. A probably case
> > is if every XMAP checks if a subdirectory is specified and just
> > provides files from that subdirectory. Fallback is useful for this
> > case:
> > If subdirectory is specified:
> > If the subdirectory contains an XMAP, mount that XMAP.
> > Else check the parent subdirectories for XMAPs.
> > If an XMAP is found, check the pipelines. Add a default pipeline that
> > passes to the parent directory's XMAP if no special pipeline is used.
> > If no XMAP is found, deliver the file specified from the subdirectory.
> >
> > This functionality is possible using combinations of the
> > ResourceExistsSelector, map:mount, and some internal pipelines. You
> > did not mention if a solution can include custom Java. The code could
> > be simplified with a DeepestXMAPSourceFactory that returns the deepest
> > XMAP in a directory path with a parameter for the deepest allowed
> > level.
> > 1. Pass to deepest XMAP, if any.
> > 2. Check matches.
> > 3. If no, default pipeline pass to deepest XMAP above this one.
> >
> > A third method of passing control is to use map:redirect. This should
> > be discouraged due to the side-effect of changing the address in the
> > browser. Another concern is the aforementioned inability to use this
> > method inside Actions.
> >
> > Let me know if this was unclear. Cocoon XMAPs can be used as a
> > programming language., but doing so may require different skills than
> > are available to you.
> >
> > solprovider
> >
> > On 2/27/08, Alec Bickerton <al...@minick.ch> wrote:
> >> I'm looking to streamline the sitemap that is being used and am seeing a
> >> few problems.
> >>
> >> First, a little bit of background...
> >> The application has evolved over a time to contain a large number of
> >> subdirectories. These subdirectories are not self contained and for the
> >> most part rely on the pipeline in the root sitemap. The upshot being
> >> that the root sitemap contains a considerable amount of project specific
> >> matchers
> >>
> >> As far as I can see, It I use the following ,Then the pipeline in the
> >> sitemap in the customer1 directory will be entered.
> >> <map:match pattern="customer1/**"/>
> >> <map:mount uri-prefix="customer1" src="customer1/sitemap.xmap"
> >> check-reload="yes" reload-method="asynchron"/>
> >> </map:match>
> >>
> >> This is almost what I need, however, I need the pipeline to return to
> >> the pipeline in the global sitemap if nothing matches so that the
> >> default matchers will get hit.
> >>
> >> An example customer sitemap would look like.
> >>
> >> <?xml version="1.0"?>
> >> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> >> <map:pipelines>
> >> <map:pipeline>
> >> <map:match pattern="*/**">
> >> <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
> >> </map:match>
> >> </map:pipeline>
> >> </map:pipelines>
> >> </map:sitemap>
> >>
> >> so for example for the request
> >> mysite.com/cocoon/projects/customer1/project2/index.html
> >> the pipeline needs to go:
> >> 1: sitemap in cocoon directory
> >> 2: sitemap in projects directory
> >> 3: sitemap in customer1 directory
> >> 4: sitemap in projects2 directory matches *.html and performs an action
> >> does not redirect as the user is allowed.
> >> 5: returns to the sitemap in customer1 directory at the point in the
> >> pipline where mount was called
> >> 6: returns to the pipeline in the sitemap in projects directory where
> >> the *.ml matcher is declared after the customer matchers.
> >>
> >> Can anyone suggest the best means for me to accomplish this?
> >> Thanks,
> >> Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Alec Bickerton <al...@minick.ch>.
Thanks for the pointer, I go and chew it over for a while and see what I
can come up with.
Alec,
solprovider@apache.org wrote:
> Cocoon has several methods to pass control between XMAPs. The best is
> map:mount because it allows non-standard protocols. (We use
> file-level fallback to discover the next XMAP so map:mount is useful
> because we can specify the fallback protocol. This is difficult with
> the cocoon: protocol mentioned next as fallback must be programmed
> into XMAPs in addition to a SourceFactory.)
>
> The basic method of passing control back to the root sitemap is to use
> a generator with the cocoon: protocol.
> <map:generate src="cocoon://yourPattern"/>
> <map:serialize type="xml"/>
> This is likely what you want. Note the double-slash:
> cocoon:/patternInCurrentXMAP
> cocoon://patternInRootXMAP
>
> I dislike Actions because standard features are disabled (e.g. no
> redirects or reads) and variables are misplaced ({1} must be changed
> to {../1}). Selectors often have similar functionality without the
> side-effects.
>
> Assuming your functionality is simple and most of the XMAPs contain
> similar functionality, you might condense your XMAPs. A probably case
> is if every XMAP checks if a subdirectory is specified and just
> provides files from that subdirectory. Fallback is useful for this
> case:
> If subdirectory is specified:
> If the subdirectory contains an XMAP, mount that XMAP.
> Else check the parent subdirectories for XMAPs.
> If an XMAP is found, check the pipelines. Add a default pipeline that
> passes to the parent directory's XMAP if no special pipeline is used.
> If no XMAP is found, deliver the file specified from the subdirectory.
>
> This functionality is possible using combinations of the
> ResourceExistsSelector, map:mount, and some internal pipelines. You
> did not mention if a solution can include custom Java. The code could
> be simplified with a DeepestXMAPSourceFactory that returns the deepest
> XMAP in a directory path with a parameter for the deepest allowed
> level.
> 1. Pass to deepest XMAP, if any.
> 2. Check matches.
> 3. If no, default pipeline pass to deepest XMAP above this one.
>
> A third method of passing control is to use map:redirect. This should
> be discouraged due to the side-effect of changing the address in the
> browser. Another concern is the aforementioned inability to use this
> method inside Actions.
>
> Let me know if this was unclear. Cocoon XMAPs can be used as a
> programming language., but doing so may require different skills than
> are available to you.
>
> solprovider
>
> On 2/27/08, Alec Bickerton <al...@minick.ch> wrote:
>> I'm looking to streamline the sitemap that is being used and am seeing a
>> few problems.
>>
>> First, a little bit of background...
>> The application has evolved over a time to contain a large number of
>> subdirectories. These subdirectories are not self contained and for the
>> most part rely on the pipeline in the root sitemap. The upshot being
>> that the root sitemap contains a considerable amount of project specific
>> matchers
>>
>> As far as I can see, It I use the following ,Then the pipeline in the
>> sitemap in the customer1 directory will be entered.
>> <map:match pattern="customer1/**"/>
>> <map:mount uri-prefix="customer1" src="customer1/sitemap.xmap"
>> check-reload="yes" reload-method="asynchron"/>
>> </map:match>
>>
>> This is almost what I need, however, I need the pipeline to return to
>> the pipeline in the global sitemap if nothing matches so that the
>> default matchers will get hit.
>>
>> An example customer sitemap would look like.
>>
>> <?xml version="1.0"?>
>> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>> <map:pipelines>
>> <map:pipeline>
>> <map:match pattern="*/**">
>> <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
>> </map:match>
>> </map:pipeline>
>> </map:pipelines>
>> </map:sitemap>
>>
>> so for example for the request
>> mysite.com/cocoon/projects/customer1/project2/index.html
>> the pipeline needs to go:
>> 1: sitemap in cocoon directory
>> 2: sitemap in projects directory
>> 3: sitemap in customer1 directory
>> 4: sitemap in projects2 directory matches *.html and performs an action
>> does not redirect as the user is allowed.
>> 5: returns to the sitemap in customer1 directory at the point in the
>> pipline where mount was called
>> 6: returns to the pipeline in the sitemap in projects directory where
>> the *.ml matcher is declared after the customer matchers.
>>
>> Can anyone suggest the best means for me to accomplish this?
>> Thanks,
>> Alec
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by so...@apache.org.
Cocoon has several methods to pass control between XMAPs. The best is
map:mount because it allows non-standard protocols. (We use
file-level fallback to discover the next XMAP so map:mount is useful
because we can specify the fallback protocol. This is difficult with
the cocoon: protocol mentioned next as fallback must be programmed
into XMAPs in addition to a SourceFactory.)
The basic method of passing control back to the root sitemap is to use
a generator with the cocoon: protocol.
<map:generate src="cocoon://yourPattern"/>
<map:serialize type="xml"/>
This is likely what you want. Note the double-slash:
cocoon:/patternInCurrentXMAP
cocoon://patternInRootXMAP
I dislike Actions because standard features are disabled (e.g. no
redirects or reads) and variables are misplaced ({1} must be changed
to {../1}). Selectors often have similar functionality without the
side-effects.
Assuming your functionality is simple and most of the XMAPs contain
similar functionality, you might condense your XMAPs. A probably case
is if every XMAP checks if a subdirectory is specified and just
provides files from that subdirectory. Fallback is useful for this
case:
If subdirectory is specified:
If the subdirectory contains an XMAP, mount that XMAP.
Else check the parent subdirectories for XMAPs.
If an XMAP is found, check the pipelines. Add a default pipeline that
passes to the parent directory's XMAP if no special pipeline is used.
If no XMAP is found, deliver the file specified from the subdirectory.
This functionality is possible using combinations of the
ResourceExistsSelector, map:mount, and some internal pipelines. You
did not mention if a solution can include custom Java. The code could
be simplified with a DeepestXMAPSourceFactory that returns the deepest
XMAP in a directory path with a parameter for the deepest allowed
level.
1. Pass to deepest XMAP, if any.
2. Check matches.
3. If no, default pipeline pass to deepest XMAP above this one.
A third method of passing control is to use map:redirect. This should
be discouraged due to the side-effect of changing the address in the
browser. Another concern is the aforementioned inability to use this
method inside Actions.
Let me know if this was unclear. Cocoon XMAPs can be used as a
programming language., but doing so may require different skills than
are available to you.
solprovider
On 2/27/08, Alec Bickerton <al...@minick.ch> wrote:
> I'm looking to streamline the sitemap that is being used and am seeing a
> few problems.
>
> First, a little bit of background...
> The application has evolved over a time to contain a large number of
> subdirectories. These subdirectories are not self contained and for the
> most part rely on the pipeline in the root sitemap. The upshot being
> that the root sitemap contains a considerable amount of project specific
> matchers
>
> As far as I can see, It I use the following ,Then the pipeline in the
> sitemap in the customer1 directory will be entered.
> <map:match pattern="customer1/**"/>
> <map:mount uri-prefix="customer1" src="customer1/sitemap.xmap"
> check-reload="yes" reload-method="asynchron"/>
> </map:match>
>
> This is almost what I need, however, I need the pipeline to return to
> the pipeline in the global sitemap if nothing matches so that the
> default matchers will get hit.
>
> An example customer sitemap would look like.
>
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <map:pipelines>
> <map:pipeline>
> <map:match pattern="*/**">
> <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
> </map:match>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
>
> so for example for the request
> mysite.com/cocoon/projects/customer1/project2/index.html
> the pipeline needs to go:
> 1: sitemap in cocoon directory
> 2: sitemap in projects directory
> 3: sitemap in customer1 directory
> 4: sitemap in projects2 directory matches *.html and performs an action
> does not redirect as the user is allowed.
> 5: returns to the sitemap in customer1 directory at the point in the
> pipline where mount was called
> 6: returns to the pipeline in the sitemap in projects directory where
> the *.ml matcher is declared after the customer matchers.
>
> Can anyone suggest the best means for me to accomplish this?
> Thanks,
> Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap pipelines
Posted by Alec Bickerton <al...@minick.ch>.
I take it nobody can help me with this... or am I just missing something
really obvious.
Alec.
Alec Bickerton wrote:
> Hi,
>
> I'm looking to streamline the sitemap that is being used and am seeing a
> few problems.
>
> First, a little bit of background...
>
> The application has evolved over a time to contain a large number of
> subdirectories. These subdirectories are not self contained and for the
> most part rely on the pipeline in the root sitemap. The upshot being
> that the root sitemap contains a considerable amount of project specific
> matchers
>
> As far as I can see, It I use the following ,Then the pipeline in the
> sitemap in the customer1 directory will be entered.
>
> <map:match pattern="customer1/**"/>
> <map:mount uri-prefix="customer1" src="customer1/sitemap.xmap"
> check-reload="yes" reload-method="asynchron"/>
> </map:match>
>
> This is almost what I need, however, I need the pipeline to return to
> the pipeline in the global sitemap if nothing matches so that the
> default matchers will get hit.
>
> An example customer sitemap would look like.
>
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <map:pipelines>
> <map:pipeline>
> <map:match pattern="*/**">
> <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/>
> </map:match>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
>
> so for example.
>
> for the request
> mysite.com/cocoon/projects/customer1/project2/index.html
>
> the pipeline needs to go:
> 1: sitemap in cocoon directory
> 2: sitemap in projects directory
> 3: sitemap in customer1 directory
> 4: sitemap in projects2 directory matches *.html and performs an action
> does not redirect as the user is allowed.
> 5: returns to the sitemap in customer1 directory at the point in the
> pipline where mount was called
> 6: returns to the pipeline in the sitemap in projects directory where
> the *.ml matcher is declared after the customer matchers.
>
> Can anyone suggest the best means for me to accomplish this?
>
> Thanks,
> Alec
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org