forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Wed, 23 Feb 2005 22:22:28 GMT
On Wed, 2005-02-23 at 12:00 +0000, Ross Gardler wrote:
> 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:generate>
>          <map:transform type="idgen"/>
>          <map:transform type="xinclude"/>
>          <map:transform type="linkrewriter" 
> src="cocoon:/{1}linkmap-{2}.html"/>
>          <map:transform 
> 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"/>
>          </map:call>
>        </map:match>
> 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.

I am doing this with forrest:views. I think that is the way for a
on-page basis.

> 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:aggregate>
>    <map:serialize type"xml"/>
> </map:match>
> 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 
> list).
> The output of each cocoon:/PLUGINAME-pageconf-*.xml would be something like:
> <org.apache.forrest.plugin.excel>
>    <disable-print-link>true</disable-print-link>
>    <disable-pdf-link>false</disable-pdf-link>
>    <extra-css>
>      ...
>    </extra-css>
> </org.apache.forrest.plugin.PDF-output>
> 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
> ==================
> Performance
> ----------
> 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.
> fbits
> -----
> How does this contribute to/intefere with work on fbits?

fbits are based on forrest:views. Anyway the RT gave me some good ideas
for the fbits. 

> alternatives
> ------------


> ????
> unforseen problems
> ------------------
> ?????
> Ross

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message