forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Tue, 01 Mar 2005 15:59:03 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.
>>
>>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.

I disagree, for the use case we have here it is very easy to achieve 
since all the CSS style information is generated by the XSL which 
extracts it from the original source document. All that is required to 
turn the hack solution in the OOo plugin into a solution that produces 
valid XDocs is to create a separate pipeline to create the CSS sheet 
rather than have it created as par of the intermediate XDoc.

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

How is this any different from <td class="color_ff000"> as I was proposing?

I see a different attribute name, but not a different design. Wouldn't 
it be better to stay consistent with XHTML2 since that will be our 
intermediate format?

The only other difference I see is where the CSS classes are defined. In 
your proposal it is in a forrest:views definition file. In mine it is in 
  some other file (skinconf.xml, pdf-output.xml or whatever):

<org.apache.forrest.plugin.PDF-output>
     <disable-print-link>true</disable-print-link>
     <disable-pdf-link>false</disable-pdf-link>
     <extra-css>
       <background-color value="#ff0000"/>
     </extra-css>
</org.apache.forrest.plugin.PDF-output>

I feel I must be missing something important about forrest:views ...

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

Yes, love the idea of fbits. However, fbits are about content in the 
page whereas this RT is about the subsequent styling of the page. I do 
not think there is *any* overlap between the two stages of production.

It may make sense to move the style configuration stuff into 
forrest:views when it is implemented, but I don't think we need to wait 
for it since I believe such a change will only require a few changes to 
the skining pipelines and stylesheets.

Is there more to it than that?

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

Sorry, I don't understand your problem, where is the code snippet from, 
is it in the intermediate docs, the XSL. I'd be happy to try and help 
solve this problem but you'll need to explain it more completely 
(probably in a different thread).

Ross

Mime
View raw message