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 ;-) Johannes
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.
Ross
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
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
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de
Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005 Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand www.uidesign.de/hmi2005
N�chstes TAE-Seminar zu User Interface Design Ostfildern-Nellingen, 07.-08. April 2005 www.tae.de TAE-Veranstaltung Nr. 31189
