forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Move plugins to trunk?
Date Fri, 15 Oct 2004 20:18:55 GMT
Dave Brondsema wrote:
> Ross Gardler wrote:
>> Nicola Ken Barozzi wrote:
>>> Now that we have released (thanks to all involved :-), I'd like to 
>>> see the new plugin system into the trunk if it doesn't break existing 
>>> behaviour. :-)
>> It's not quite ready for that. There are two small jobs to do:
>> 1) automate the last stage of plugin automation (i.e. write the 
>> sitemap snippet into the plugins sitemap)
> I haven't looked at the plugins code yet, so I might be way off here.. 
> but if we could write a cocoon generator (or other thingy.. I don't 
> know) to automatically pull the current plugins that'd probably be much 
> better than having to update a plugins sitemap.

I don't know about that. Each individual plugin has a sitemap that 
defines its functionality. These are mounted by the plugin sitemap which 
in turn is mounted by the Forrest sitemap. I'm not sure how a cocoon 
generator would reproduce that functionality, all I know about 
generators is what they do, which, IFUC, is generate content for a 
cocoon pipeline. That does not seem to be the same as deciding how to 
process a call which is the job of the sitemap.

> For simplicity's sake, wouldn't it be ok to just have the user modify 
> that sitemap?  It's in the project dir, right?

It's in FORREST_HOME/plugins so no, it does not make sense for the user 
to maintain it, besides the whole idea of plugins (at least for me) is 
to make it easier for the user to extend Forrest without having to get 
their hands dirty with sitemaps and without the core Forrest sitemaps 
getting so cluttered that they are unmaintainable. All that needs to be 
done is to add a mount for the plugin specific sitemap. Really simple 
XSL transformation will do the job.

>> 2) write a configuration system so that any functionality we take out 
>> of  Forrest core will automatically be included, unless explicitly 
>> excluded. This is to maintain backward compatibility. My idea is that 
>> we have a property in like:
>> required.plugins=openOffice, docbook, IMSManifest
> Sounds good, the property probably should have a "project." prefix.



View raw message