forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Docbook as forrest-plugin
Date Mon, 25 Oct 2004 07:54:22 GMT
Sean Wheller wrote:
> On Monday 25 October 2004 04:11, Ross Gardler wrote:
>>What is your reasoning for using this directory layout rather than the
>>one currently adopted. Unless there is a good reason it would make much
>>more sense to stick to the same format as all the other plugins, and
>>Forrest core itself - it will be less confusing for developers dropping
>>in on the code.
> 1. shorter paths, fewer folders. My thinking is to only use a folder when it 
> is required. Seemed to me that resources/ was not doing anything much. It 
> made sense in the core, but does it makes sense in a plug-in? The plugins/ 
> already does the work that resources/ did. Plugins/ contains folders named by 
> the plug-in e.g. openoffice, feeder, IMSmanifest, docbook, SVG, WSDL, dia 
> etc. It just made sense that the resources for a plugin are contained in the 
> plugins/[plugin-name]/

I disagree. It makes sense to have a resources dir as it makes sense to 
have a src dir for a project. I don't want to mix actual resources with 
conf info.

Theorically we could have it the other way around:

        ** all the stuff now in resources
        FOR-INF/ the configuration files

but it makes it a royal PITA to reference things backwards.

If you favor to use the simplest thing, in this case it's simpler not to 
deviate from preceding behaviour.

> 2. IMO plug-in is an object that adds a content type class, configuration, and 
> resources to forrest. I would actually change the directory name from plugins 
> to frameworks. 

-1 It simply does not make sense. A framework is something used to build 
upon (IOW white box), while a plugin is the exact opposite.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message