forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Wed, 23 Feb 2005 12:00:00 GMT
Johannes Schaefer wrote:
> Is there a valid way to specify a specific style for a
> single element in document-v1.3 (or v2.0)?
> The only way I see is to use a class attribute but this is
> not possible because each and every cell may have a
> different bg-color.

[Note what I am thinking about here is quite a bit of work, I'd suggest 
that if anyone tackles it they should do so in a branch so that there is 
no danger of it messing up the 0.7 release.]

The Problem

In Forrest we have always insisted that the source document should not 
contain any style information. However with our increasing support of 
other formats we are losing control of this in some cases. Already there 
are two solutions in two different plugins.

I really don't like the idea of embedding style information into the 
style attribute of the Intermediate format as is the current solution 
for the Excel plugin. Similarly I do not like the solution I hacked for 
the plugin (en embedded style element in the header).

I think we need to devise a solution for use in Input plugins that will 
be the "official" way for Forrest to deal with embedded style 
information. Note that I am *not* suggesting we allow style information 
into documents written specifically for Forrest, just that we handle 
documents with embedded style information in a consistent way.

This means that at the intermediate format must allow skin information 
to be extended, but how?

A second, but related problem, is the feature requests we have for per 
page configuration of the skin. Some people want to turn the PDF button 
on or off on a per page basis, others want to change the logo images at 
the top of the page.

fbits are a proposed solution to this. I'm not sure how this RT fits in 
with fbits or if it stomps all over the fbits proposal. That is why this 
is an RT (random thoughts) rather than a proposal. I want to see if it 
all fits together.

Generating skinconf.xml

Recently, Bastian Bowe showed us how we can customise skinconfig on a 
per plugin basis 
( I 
think if we extend this idea a little we could have plugins generate the 
extended config info.

Consider this match (hint: the map:generate of the current sitemap has 
been replaced by map:aggregate):

       <map:match pattern="**body-*.html">
	<map:aggregate element="page">
	  <map:part src="cocoon:/{1}{2}.xml"/>
	  <map:part src="cocoon:/{1}pageconf-{2}.xml"/>
         <map:transform type="idgen"/>
         <map:transform type="xinclude"/>
         <map:transform type="linkrewriter" 
src="resources/stylesheets/declare-broken-site-links.xsl" />
         <map:call resource="skinit">
           <map:parameter name="type" value="document2html"/>
           <map:parameter name="path" value="{1}{2}.html"/>
           <map:parameter name="notoc" value="false"/>

here we are adding configuration info for individual pages 
(cocoon:/{1}pageconf-{2}.xml). Therefore it can do things like add CSS 
styles or change some default behaviour, such as whether the PDF button 
should be displayed or change the logo's on individual pages etc. 
skinconf.xml now becomes the specification of the default behaviour.

In the event of a conflict between different plugins we would give 
precedence to the one that appears first in the list of plugins in (this is reflected in the order that the conf 
elements appear). This conflict resolution may turn out to be too 
simplistic, but I am sure it will work in the short to medium term. A 
longer term solution can be found later.

Generating page config

Each plugin must be able to contribute to the page config, so we will 
need a new matcher that will aggregate all the pageconf contributions 
from the individual plugins. I don't think Cocoon is able to do this and 
so this match will have to be created in the same way that the relevant 
plugin mounts are created (see targets/plugins.xml). The pageconf match 
will appear in the generated internal.xmap file and will look like this:

<map:match pattern="**pageconf-*.xml">
   <map:aggregate element="pageconf">
     <map:part src="cocoon:/PLUGINNAME_1-pageconf-{1}{2}.xml/>
     <map:part src="cocoon:/PLUGINNAME_2-pageconf-{1}{2}.xml/>
     <map:part src="cocoon:/PLUGINNAME_3-pageconf-{1}{2}.xml/>
   <map:serialize type"xml"/>

Within each plugin sitemap we will find:

<map:match pattern="PLUGINNAME-pageconf-*.xml">

Since we are using a cocoon match to create the config we can use really 
simple techniques for configuration (like a file) or 
we can do really clever stuff like the include/exclude patterns for 
enabling specific page features such as PDF buttons (as discussed on dev 

The output of each cocoon:/PLUGINAME-pageconf-*.xml would be something like:


In most cases (i.e. all but extra-css) the values in here override those 
in skinconf.xml and other pageconf elements. The extra-css values are 
added to those in skinconf.xml and elsewhere in pageconf.

Using page config

To use this information we simply need to modify any code that works 
with skinconfig.xml. We would first look for a value in the pageconf 
element, if it does not exist we would use the one in skinconf.xml instead.

Issues to Consider


There is potentially a large impact on performance here as we are 
considerably increasing the number of matches for each page. This is 
mitigated to some extent by only using the plugins applicable to this 
site, but nevertheless the impact could be quite large. Of course, 
Cocoon's caching will help considerably in most cases.


How does this contribute to/intefere with work on fbits?



unforseen problems



View raw message