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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
