forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Sat, 30 Oct 2004 23:04:44 GMT
Dave Brondsema wrote:
> Thorsten Scherler wrote:
>> Hello devs,
>> I have not really had a deep look into our new plugin mechanism but I
>> really like the idea of having atomic parts in forrest. Maybe 
>> everything that follows is not possible yet but I reckon that it will 
>> be. ;-)
>> The idea is to move the skins into a plugin like the
>> plugin. BTW I reckon we have to capsulate the pdf into a plugin for its
>> own. IMO it should be not in the skin. IMO this part will need some
>> loving care in the future. ;-) I reckon we can call it fo-plugin.
>> The skin-plugin should be the main plugin for all skin related issues. 
>> It is what I would refer to as top level plugin that can host 
>> different sub-plugins. This way it should be possible to reuse our 
>> skin-functinality even better and more efficient.
> PDF (via FO) generation already uses values from skinconfig.  It will 
> continue to do so even more.  Probably most of the settings are 
> different than those used for HTML generation, but there are (or can be) 
> a few common ones (such as project name, copyright, etc).  Any solution 
> relating to skins needs to be capable of applying skinconfig values to 
> any output format.  Much of this will probably depend on the new 
> skinconfig format (which needs to be revised in light of output-plugins).
> It is also possible to have different skins for PDF output.  Why not? Or 
> different skins for SVG output.  Or TXT output.  Just because most of 
> our skinning is for HTML currently doesn't mean that is all we need to 
> think about.

This is all true, and I have to admit that when I first started replying 
to Thorstens post I included my example use case - that is I produce 
exam papers using Forrest, past exam papers use a different PDF skin to 
current ones. However, as I thought more, and absorbed the implications 
of what Thorsten is proposing, I realised that since a skin will conform 
to a standard definition (as should plugins generally) there is no 
reason why a plugin cannot pull values from the skin, we know they will 
be there, since there must be at least one skin available.

(of course I would be more careful about making a plugin dependant upon 
another type of plugin - but I'm sure that day will come)


View raw message