forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <s...@inwords.co.za>
Subject Re: [RT] plugin infrastructure
Date Thu, 04 Nov 2004 14:18:28 GMT
On Thursday 04 November 2004 15:30, Nicola Ken Barozzi wrote:
> I'm thinking of the DocBook plugin and plugins that output the DocBook
> as Sean has shown... so there is a dependency
>
>    DocBook_outputting_plugin-> Docbook_plugin -> Forrest
>
> A solution to this would be Cocoon Blocks, but they would still
> need some sort of automatic resolution for us to be of use.

Sorry to cut this message so short. There are lots of good ideas in it. 
However, at the risk of sounding stupid and being totally simplistic, perhaps 
there is another solution.

Perhaps a solution is to force some level of filesystem organization on users. 
By this I mean, that if a user has Docbook files, then they should store them 
in the same folder. If a person has OO.org files they will be in another 
folder. This means that we can allow the user to specify the content type 
expected by the folder. Instead of matching by file extension, we match by 
folder. All resources, including images are stored within this folder. 
Forrest does not try to determine image locations, css, javascript etc. 
locations. This is defined by the transformation stylesheets.

Forrest would need properties to be provided so that supported content types 
are mapped or associated with 0 or more paths.

When a property is not set = "0", that content type is seen as non-existant in 
the system. When set it to a value of "1" it will automatically look for the 
paths where such content type resides and the plug-in and sitemap to use.

I also think that mapping to a path is more efficient than mapping explicitly 
to files with a given extension.

Does anyone think this could work?
-- 
Sean Wheller
Technical Author
sean@inwords.co.za
http://www.inwords.co.za

Mime
View raw message