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 Tue, 01 Mar 2005 14:29:03 GMT
On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
> Johannes Schaefer wrote:
> > With what is proposed now would I have to define a
> > lot of classes like class="color_ff00ff" and define
> > these classes in the file-specific config?
> Take a look at the OOo plugin. It does exactly this with a similar file 
> format, although it places the style stiff in the xdoc so this is only a 
> partial solution, but at least it uses classes. Perhaps you can try and 
> replicate for the Excel sheet to see if it works. Here's a where to 
> start looking:
> In the root template we have
>        <header>
>          <title>
> 		....
>          </title>
>          <xsl:call-template name="style"/>
>        </header>
> The style template looks like this:
>    <xsl:template name="style">
>      <style>
>        <xsl:apply-templates select="//office:styles/style:style"/>
>        <xsl:apply-templates select="//office:automatic-styles/style:style"/>
>      </style>
>    </xsl:template>
> The rest of the templates you can easily trace from here. We match all 
> the style information that we want to allow through to the skinning 
> stage, therefore it would be possible to configure which style 
> information we allow and which we disallow on a per document basis.
> With this RT this style information would be extracted with the request 
> for the plugin config stuff rather than embedded in head.
> Can this work for Excel sheets?
> > Or would I need to extend the DTD to validate this
> > single file and provide an XSL fragment (like extra-XSL)
> > to translate it?
> No, we do not want style information in our intermediate format so no 
> extending the DTD.

The problem that I see is that if you have a table with many colored
fields and all have different colors that can be pretty soon overkill. I
understand that the intermediate format should be clean of style
information but I reckon it will be pretty hard to achieve.

Now to the promised example, I would place the style information into a
forrest:view like:

<forrest:hook name="color_ff0000">
  <background-color value="#ff0000"/>

Then I would add this to fileSpecific.ft (ft = forrest template) add it
to an aggregation and match it in the xsl. 

In the document I would recommend to add an attribute <td
ft="color_ff0000"/> that will be matched in the xsl.

The whole thing do not have much to do with fbits. I am just using the
forrest:views as config file format for the fbits.

fbits are capsuled code snippets that can be called by a forrest:view.
The fbit plugin has a method "get.fbits.*" (in form of an URL) which
will return the snippets. * has to be replaced by the name of the fbit.

The only problem that I am facing and that is why I do not really get to
the point of releasing it is that I am facing the problem of how to
resolve the variables of the snippets before I parse them to the code.

e.g. <img class="skin" src="{$skin-img-dir}/poddoc.png" alt="POD -
icon" />.

I will have to return to work, but fell free to ask question and suggest

> > Just my part of RT ;-)

...and my. ;-)

> I'm glad you spoke up, it is your post that prompted me to write this RT 
> it has been knocking around on my To Do list for some time. Now there 
> are three of us with a strong use case (Thorsten is the third) it should 
> be easier to discover a suitable solution.

yeah I will hope as much as I can ATM.

> Ross

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

View raw message