Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of solprovider@gmail.com
 designates 72.14.214.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Hk7ynfNBvwpQME04G4aJJRIdI85Rh1bNY2BXDbmKXtTRMNKJNPxd3RwlQJhlLCYX7crBXC7O1RZiIa/huucoProEBfO6KUkQNEfIkIQI637VNDfssdDGx3enJ3VA+fHQfkwW04hkkhy7S5e6Ed+W7EiwNWb12nrtfASM/+8skl0=
Message-ID: <dfe834320803041847v2e357d31s888a0c1b09b38a2@mail.gmail.com>
Date: Tue, 4 Mar 2008 21:47:40 -0500
From: solprovider@apache.org
Sender: solprovider@gmail.com
To: users@cocoon.apache.org
Subject: Re: Sitemap pipelines
In-Reply-To: <47CD8661.30900@minick.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47C55F69.6050407@minick.ch>
	 <dfe834320803032315s1fb4c022na223375d9b9df13d@mail.gmail.com>
	 <47CD8661.30900@minick.ch>

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 <alec.bickerton@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 <alec.bickerton@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