forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Excluding files?
Date Thu, 11 Jan 2007 09:31:35 GMT
Ross Gardler wrote:
> Cameron McCormack wrote:
>> David Crossley:
>>> Yes. See some examples in forrest/site-author/conf/cli.xconf
>>> Not an "error". Doing 'forrest site' follows every link that it finds.
>>> The Cocoon CLI (Command Line Interface) config enables the
>>> powerful exclusion mechanism.
>> Ok.  Is there a way to configure it so that if it follows a link it
>> doesn’t know how to generate, but that file is in the content directory,
>> that it doesn’t consider it an error?
> I've done this on a few sites. There are three approaches (that I can 
> think of):
> In the first, you provide a pipeline at the end of all other pipelines 
> that generates a "File not found" type XDoc. This pipeline will be the 
> final one processed and so will ensure a document is always returned. We 
> don't have one in the default distribution as this will hide build 
> errors that are really build errors, but it has the advantage of 
> covering all possible requests that are not matched by other pipelines.
> Note that this first approach requires you to modify Forrests core 
> sitemaps and thus you will need to be careful when upgrading.
> The second approach is to create a dummy file for each unmapped request. 
> This dummy file will say something like "This will be a dynamically 
> generated page in the live system". This works well, but requires you to 
> manage each page individually, however it requires no changes to the 
> core sitemaps. Note that you may need to add a pipeline to match special 
> request patterns that Forrest does not normally match (e.g. "*.cgi").
> The final approach is a half way between the first two. Create a set of 
> pipelines in your project to match the requests affected by your issue. 
> these will need to be narrow enough to trap all known pages but allow 
> all others to pass through. The downside of this is that it can be 
> difficult to identify a suitable pattern (or set of patterns), I'd 
> recommend using the RE matcher for this unless you only have one or two 
> pages affected by this.

One important clarification is that when deploying the site you need to 
ensure that the hosting environment does not serve the page Forrest 
generates but serves the one intended, i.e. a CGI script.

Thorstens overlapping mail showed how to do the third approach I 
describe. However, in his case he was providing the source documents, I 
guess this is what you intended for the "*.java" request but not for the 
"*.cgi". then again, my guess could have been wrong.


View raw message