forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Schaefer <>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Tue, 01 Mar 2005 15:40:08 GMT
Thorsten Scherler wrote:
> 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.

In the OOo plugin the style information is available
*before* writing the output. In the Excel plugin the cell
content determins the style (i.e. color) of it. I would have
to do a pre-processing step to create all the classes
(styles) and put them into the header
(anybody to suggest how?).

But this is not where the discussion is heading ... the
style information should be neither in-line nor in-header.

>>With this RT this style information would be extracted with the request 
>>for the plugin config stuff rather than embedded in head.

If it was to write a separate file (like a template), this
could be done I think (again: how?).

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

Right, putting each color into a class/ft could explode
the style section.

We now have about 25 basic colors but I don't know what
others will come up with (or other projects).

> Now to the promised example, I would place the style information into a
> forrest:view like:
> ...
> <forrest:hook name="color_ff0000">
>  <css>
>   <background-color value="#ff0000"/>
>  </css>
> </forrest:hook>
> ...
> 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.

For me it would be sufficient to have @class. No new
attribute @ft needed. The question is, how and where
can I define the classes? They need to make it into
CSS-classes at the skinning stage (like Excel-CSS).

I still cannot see a big difference between a
       class=" background_color__ff0000  "
and a style="{background-color=#ff0000;}"

Both look to me like style information ;-)

This is different in the OOo where styles are used
consistently throughout the document.
In the Excel plugin it's basically a one-time use.

Just another bit ;-)

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

User Interface Design GmbH * Teinacher Str. 38 * D-71634 
Fon +49 (0)7141 377 000 * Fax  +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * 
Lehrer-Götz-Weg 11 * D-81825 München

Buch "User Interface Tuning" von Joachim Machate & Michael 

Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005
Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand

Nächstes TAE-Seminar zu User Interface Design
Ostfildern-Nellingen, 07.-08. April 2005 TAE-Veranstaltung Nr. 31189

View raw message