forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] RAW content
Date Fri, 26 Nov 2004 18:57:31 GMT
Juan Jose Pablos wrote:
> Ross Gardler wrote:
> 
>>
>> If the content developer identifies the directories/files that are RAW 
>> then Forrest can handle them differently (a RAW plugin).
>>
>> The .source.html extension is only required if we need the source 
>> format of a none-raw file.
>>
>> Ross
> 
> 
> Mcplugin is back :-)

(did you know I was born in Scotlant so the "Mc" part of this is 
actually quite appropriate - I suppose the "Ross" may have given it away)

> 
> Well, one of your mails about matching make me think that this is all a 
> problem with selections & actions.
> 
> In forrest we usually select a group of files base on directory, name or 
> extension. (And the clever source validation) and then we do some action 
> base on that.
> 
> So in fact we are creating "name dependencies" like "use faq-***" for 
> faq etc... than we do not know what to do with that ( Have you seen 
> entries about backwards-compat with 0.2 - 0.4? )
> 
> 
> So instead of getting this. How about providing users with examples on 
> how to extend that funcionality with sitemaps?
> 
> This is a custom sitemap that you can use if you have a javadocs directory:
> 
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>  <map:components>
>  <map:readers default="resource"/>
>  </map:components>
>  <map:pipelines>
>   <map:pipeline>
>    <map:match pattern="javadocs/*">
>     <map:read src="{project:content.xdocs}/{0}" mime-type="text/html"/>
>    </map:match>
>   </map:pipeline>
>  </map:pipelines>
> </map:sitemap>

+1 although I would put it in a plugin of course ;-)

Why bother putting something as simple as this in a plugin? For the 
future...

Imagine we have a javadocs plugin. It provides the following properties 
to forrest.properties:

forrest.plugin.javadoc.include
forrest.plugin.javadoc.exclude

If those properties do not exist in a users forrest.properties file then 
they take default values of:

forrest.plugin.javadoc.include=javadocs/*
forrest.plugin.javadoc.exclude=

Then we write a new matcher for Cocoon (I am assuming there isn't one 
that does this already). This new matcher reades the relevant properties 
from forrest.properties and matches files accordingly.

Why is this important? It is a way of maximising the users control over 
their URI space without them having to edit XMAP files.

Ross

Mime
View raw message