forrest-dev mailing list archives

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

I am sorry I did not had enough time to really get into the actual
problem. In the Indesign Plugin I am doing a similar thing. I let the
designer create all objects and styles and I just parse the content. 

I already have the content separated from the style at this stage. I
only need to match from the user data to the design object. This
matching is configured by forrest:views. forrest:views are just
configuration files for controller and matching engine.

In the end I would like to alter my application in changing
configuration files (CheChe will now laugh ;-) when I meet him I think
all my solutions ended up with a config file). 

I see the skinconf.xml problematic because there is not a common
structure. Your solution as well is not abstract enough IMO:

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

When I want to match a new plugin I would need to add a new match in the
controller. That is the reason why I would like to do it with
forrest:views, where you have three different kind of main tags (so far)
which all have certain functions. The other thing is I would like to
have a skinconf per page basis, but that not make much sense if I am
using our current skinconf because it is to mixed up.



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

It is not I thought it should not be done with @class. Sorry for the noise.

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

This discussion was a wake-up call for me to finish the fbits-plugin. I hope I can establish
a proof-of-concept
example with the 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.
> 

...and this point I see different. I see the problem as follow:
In a skin there the content is placed on certain positions. 
The skinconf determines whether or not the content should be placed but not where. 
ok that is not 100% true because e.g. pelt have two different position for the breadtrail.

I would like to use the skinconf in a way which will determine the position of elements. I
see
forrest:views as the next generation skinconf. I can place elements and e.g. the fbits will
be then 
inserted on this position. I do not need something like <disable-print-link>true</disable-print-link>
because if I do not place the <forrest:nugget name="print-link"/> in my view this link
will not get rendered.

Now where I see an overlap is that I could easily add css to the <forrest:nugget name="print-link"/>
like (or similar)
<forrest:nugget name="print-link"> 
 <css>
   <background-color value="#ff0000"/>
 </css>
</forrest:nugget>

That would solve another thing that I do not like on our current skinconf. The color tags
are not self explaining. 
I would like them in the element that they are changing. 

The last thing that I do not like on skinconf that it is 100% forrest specific and I can not
reuse it in e.g. lenya.
Gregor wrote yesterday in the lenya-dev list:
"the plus side of forrest plugins is that they exist today and address an 
area where lenya is weak today (resource type packages). on the minus 
side, it seems to rely heavily on skinconf.xml (very forrest-specific) 
and seems stuck in the DTD world. (note that i did not take a very
close 
look, so i might be wrong)"

I have to agree on BOTH minuses. ;-)


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

Yes and no. IMO it will be a major break for skins, because there will be no more. Skins are
not flexible.
I want something that I can change within a minute without touching xsl code. It should be
after the KISS motto.
Keep It Simple and Successful. 

A forrest:view can alter a whole site or only pages.

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

You already did it (kind of). I was trying to reuse a lot of stuff without major changes,
but I think that is not wise.
I will try to hack a solution over the weekend and would be really happy if you (ant others
of course) will comment on it.

> 
> Ross
-- 
thorsten

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


Mime
View raw message