forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Solving matching problems caused by plugins
Date Sat, 30 Oct 2004 13:25:07 GMT

David Crossley wrote:
> Ross Gardler wrote:
>>Dave Brondsema wrote:
>>>Ross Gardler wrote:
>>>I think that's the right idea.  Lots of stuff can be moved to be a 
>>>plugin.  For example, changes/todo.html as a plugin would make that 
>>>functionality optional and so people can use those reserveds names.
>>>I haven't tried yet.. does the plugin location allow for input formats 
>>>and output formats?
>>I'm starting to think that we need a more flexible plugin system that 
>>would allow insertion at different points in the generation process.
>>For example, IMSManifest is currently broken because of having to move 
>>the plugin sitemap mount to *after* the generation of things like 
>>site.xml, faq.xml etc.
>>Your question about input and output formats is another point, output 
>>formats would need to be mounted in a different location from the input 
>>formats (which is all I have worked with to date).
>>I was thinking of moving to a system where plugins can provide three 
>>preprocessing (comes before *everything* in core - such sitemaps would 
>>have to be very careful to only match what they need, i.e. IMSManifest 
>>would match abs-linkmap, site.xml. tabs.xml etc.)
> Already the project sitemap.xmap must be careful to
> only match what they need.
> So where does their project sitemap fit into this?

Yes, and I suspect that this will start to cause us real problems. As 
Dave Bronsema suggested earlier in this thread, we need to create a 
contract for plugins. I think this same contract can be used for the 
project sitemap. In the meantime we'll leave project sitemap where it is 
since we will learn more about the correct handling through working with 
the plugins.

>>input formats (these would be placed where the current mount is, i.e. 
>>just before the default **.xml match in forrest.xmap)
> Would a project sitemap still be able to match those
> if they needed to?

Yes, the project sitemap is (and will always be) mounted before the 
plugins. In other words, the order of processing precedence would be 
project -> plugins -> forrest.

There is the question of which plugin gets preference since there could 
be conflicts. Right now I have done two things to try and tackle this:

1) only the plugins required for the current project will be mounted, 
regardless of what plugins are on the local HD

2) plugins will be processed in the order they appear in the 
project.requried.plugins property

I believe this will be sufficient for the time being. For example, it 
will handle the overlap between the current simplified-docbook plugin 
and the proposed full-docbook plugin.

> [snip]
>>>We will also have to document a "plugin contract" of what pipeline parts 
>>>will be made available and supported.  I think we have need to work 
>>>through some more real examples of plugins before we fully understand 
>>>their power and limitations.  Then we can best write the contract.
>>I agree. I will, over the coming weeks move all none core functionality 
>>from core into a plugin. That should give us a fair number of use cases 
>>to at least draft the contract from.
>>The question at the moment is where to *stop* moving stuff into plugins.
> Bit-by-bit until we can understand the core sitemaps again.
> If we start to duplicate functionality in each plugin, then
> it will become apparent where to stop.

OK sounds wise. I'll keep going until someone holds up a stop sign (I 
suspect I may miss it myself - extracting plugin code is quick reward 
stuff - much better than building flat pack furnitre ;-))


View raw message