forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Sat, 30 Oct 2004 23:44:19 GMT
Dave Brondsema escribió:
> Thorsten Scherler wrote:
> 
>> The idea is to move the skins into a plugin like the OpenOffice.org
>> 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.
>>

...

> 
> PDF (via FO) generation already uses values from skinconfig.  It will 
> continue to do so even more. 

Seeing that can mean that we have values in the skinconfig that there 
are more common. I mean this data can be used by x plugins and do not 
have to be kept locally stored in the plugin.

I see the skinconf.xml as the aggregation of properties that are need 
for the skin-plugin. Saying that I would but the following values in a 
common-data.xml:
   <!-- mandatory project data -->
   <project-name>MyProject</project-name>
   <project-description>MyProject Description</project-description>
   <project-url>http://myproj.mygroup.org/</project-url>
   <project-logo>images/project.png</project-logo>
   <!-- Alternative static image:
   <project-logo>images/project-logo.gif</project-logo>

Something that is needed by only the html-plugin would go into a 
xhtmlconf.xml, like
   <!-- Disable the PDF link? -->
   <disable-pdf-link>false</disable-pdf-link>

  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).
> 

I agree with you. I just think that e.g. common-data has to be moved out 
the skinconf.xml. We still can read them with the skin-plugin but other 
plugins too.

e.g. a WYSIWYG editor can change the name and the copyright.

> 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.

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.

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.

The problem that I see with the skinconf.xml is that we do not have a 
clear seperation of concerns. I now got a wee bit into the html skining 
and never touched anything from pdf.

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.

like:
skin-plugin
+-xhtml-plugin
++-xhtml-functionality
++-xhtml-css
++-xhtml-skelleton
+-pdf-plugin
+-docbook-plugin


> I like your ideas; moving stuff skinnable output into plugins will make 
> Forrest much more powerful and flexible.
> 

Cheers. :)

thorsten


Mime
View raw message