Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (hermes.apache.org: domain of
 cjxaf-forrest-dev-1@m.gmane.org designates 80.91.229.2 as permitted sender)
To: dev@forrest.apache.org
From: Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: [RT] plugin infrastructure
Date: Sun, 07 Nov 2004 23:09:08 +0100
Lines: 57
Message-ID: <cmm6e4$o1k$1@sea.gmane.org>
References: <cmab28$uo$1@sea.gmane.org> <4188E497.4080803@apache.org>
 <cmdast$dd0$1@sea.gmane.org> <418BB394.3090909@apache.org>
 <cmi7tb$7ls$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
In-Reply-To: <cmi7tb$7ls$1@sea.gmane.org>
Sender: news <news@sea.gmane.org>

Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
...
>>>> My Proposal
>>>> ===========

I'll add something to my previous mail. When replying, please stitch the 
two together :-)

>>>> Each plugin should be able to provide three sitemaps rather than the 
>>>> current 1.

When Dave has asked to rename the last plugin to show that it's an 
output plugin, alarm bells started ringing in my head. I had not 
pondered it enough, and the separation that was hinted became clearly 
needed.

IOW, I now understand what probably has been plain obvious to all others 
:-) : we *must* have each plugin use only one of the following sitemaps.

>>>> - sitemap.xmap - this provides the infrastructure matchers (i.e. 
>>>> site.xml, faq.xml, issues.xml), as such it will be mounted before 
>>>> *any* of the Forrest matches. This sitemap can override any 
>>>> behaviour within Forrest)
>>>>
>>>> - source.xmap - this provides the source matchers (i.e. **.xml), it 
>>>> is mounted in forrest.xmap before the default forrest **.xml 
>>>> behaviour and therefore can override that default behaviour but it 
>>>> will not interfere with any internal Forrest infrastructure matches, 
>>>> or any other plugins infrastructure matches.
>>>>
>>>> - output.xmap - this provides (surprise!) the output matchers (i.e. 
>>>> **.html, **.pdf, **.slides), it is mounted before any of the default 
>>>> matchers for Forrest and so can override this default behaviour
>>>>
>>>> Ideally, each plugin should only provide one of these three 
>>>> sitemaps. I believe this will help us to define a sensible 
>>>> granularity for the plugins. However, further exploration of use 
>>>> cases may show otherwise and therefore we should make it legal (but 
>>>> not encouraged) to implement more than one of them.

As said above, it seems that we now have to make it unlegal.

This gives us the problem of libraries and components in each plugin, as 
more plugins can need the same jars or cocoon xconf extensions.

Hmmm...

Also, we have to define a contract with plugins, so that they use an 
inputmodule to get the source files and the requested uri, in case we 
will go to plugin dependencies, and or the locationmap inserted later.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------