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 OpenOffice.org 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
> (http://marc.theaimsgroup.com/?l=forrest-dev&m=110873270020951&w=2). 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
> forrest.properties (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 plugin.properties 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
> ------------
>
forrest:views
> ????
>
> unforseen problems
> ------------------
>
> ?????
>
>
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
