forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Sun, 31 Oct 2004 17:56:50 GMT
(having just posted a mail saying I'm withholding comment, I discovered 
this mail from much earlier today was still sitting at the spell check 
stage, since I already wrote it I'm posting it anyway)

Thorsten Scherler wrote:
> Dave Brondsema escribió:
> 
>> Thorsten Scherler wrote:
>>

<snip/>

>> 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.
>>
> 
> Maybe we should have the pdf-plugin as subplugin of the skin-plugin.

This is what made med think that plugin is probably not the right name 
for what you are proposing. It will get confusing. I would suggest we 
stick with skin for your main "controlling" "plugin" and go with 
skin-plugin for things like PDF (and all other output stage plugins).

> Like I stated before I like to have atomic parts in forrest. Plugings 
> are for me an aggregation of functionality. These functionality can have 
> dependences on other atomic parts.

This kind of inter-plugin dependency is almost certainly going to become 
a necessity. However, I don't want to start thinking about that until we 
have solidified exactly how the plugins will work. The current 
architecture is not flexible enough to do everything we need, but it is 
getting there.

With the plugins I do not want to allow a plugin to access anything 
available in another plugin. If it is not available in core then a 
plugin cannot use it (again, I expect this to change in the future but 
want to keep it simple at this early stage). In your original post you 
said a skin plugin would be a container of sub-plugins. If we stop 
thinking about the container as being a plugin but start with it as a 
part of core then that means values that are needed by your skin-plugins 
can share values through core.

> The idea is that you can have this different pdf skins but there 
> independent from the xhtml skin. I would like to choose from a wide 
> range of pdf-skins, xhtml-skins.

Let me make sure I understand where this is going and if my slight 
alteration of your proposal fits your ideas:

Plugins deal with the input stage and are managed by core. Examples of 
these plugins are:
  - IMSManifest
  - OpenOffice.org
  - Wiki
Examples of the kind of shared values provided by core are:
  - project:xdocs
  - forrest:stylesheets

Skins (part of core) manages a series of skin-plugins. Examples of these 
plugins are:
  - XHTML
  - PDF
  - SpeechML
Examples of the kind of shared values provided by core are:
  - project.name
  - project.copyright
  - project.url

> I would suggest to split apart the skinconf.xml in subconfigs. The 
> remaining skinconf.xml would include links to installed subplugins. 
> Where the subplugins are responsible for keeping their own specific data.

With the above model do we get the kind of separation that you think we 
need? As I said I am concerned about having plugins maintain their own 
set of properties since that will encourage plugin dependencies.

If the above doesn't work let me throw in a totally random idea that I 
have not even started to think through:

How about we have another kind of plugin called a "configuration 
plugin". This will provide project specific configuration details. 
Plugins are allowed to depend on these, but not on each other?

Ross


Mime
View raw message