forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list])
Date Thu, 03 Mar 2005 21:36:49 GMT
Thorsten Scherler wrote:
> On Tue, 2005-03-01 at 15:59 +0000, Ross Gardler wrote: 
>>Thorsten Scherler wrote:

I'm only going to reply briefly to most of your points. But I will be 
brief (well brief by my standards ;-)) because of the conclusion I come 
to. I recommend reading to the end before replying as you may find it 
saves you time (I sometimes reply as I read).

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

Yes, I see your point. *If* we were to go this way we would want 
something like (note the *if*, it becomes very important further on):

<pluginConf name="org.apache.forrest.plugin.pdf-output">
   <param name="disable-print-link" value="true"/>

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

No need to add anything to the controller, the directory generator will 
provide a reference to all the plugin files.

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

Well my proposal is replacing skinconf and moving all the relevant parts 
to a plugin specific configuration. Again, I'm having difficulty 
understanding how this is different from your proposal (other than 
document syntax).

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

This is the point that leads me to my eventual conclusion, read on...

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

With the existing setup this is true, but we are discussing how this 
would change.

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

OK, I see your point. I am still lost here since the position of the 
content does not affect the content. This is still presentation detail 
and therefore not part of the fbits.

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

OK, yes I get this point, this particular value is about content not 
about skinning (I remember I made this very point to Nicola in a 
previous thread, seems I forgot it ;-) It should not be included in my 
skinconf stuff, it certainly belongs in fbits.

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

could != should

If I want to render two copies of a site, one with the print-link and 
one without I now have to duplicate all the CSS stuff across both config 
files. Similarly, if I want to use the same CSS class in a different 
fbit I now have to duplicate across two forrest:nuggets. Would it not be 
better to have:

<forrest:nugget name="print-link" class="formatButton">

And then elsewhere, in some other skin config file:

   .formatButton: background-color value="#ff0000

(or whatever syntax we want)

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

IS this worth the trade-off of an unfamiliar syntax for CSS designers 
and reduced reuse?

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

Agreed, how does your proposal address this?

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

I would also agree, the first point is what we are discussing here, so 
that is being addressed and the second is addressed by and (both scheduled for 0.8)

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

Interesting I say Keep it Simple, Stupid, but I guess your version is 
more polite :-)) Either way, neither of these approaches requires anyone 
to touch XSL. Admittedly, I am not addressing the *layout* issues 
(although CSS can do layout too, but that is not my intention since it 
is a nightmare with regards cross browser compatability).

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

How? What is forrest:views equivalent of the include/exclude patterns of 
my proposal? (read on before taking the time to answer)

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

I do think that our views (I'm including Nicola here) are very similar, 
but we have different implementation ideas. At the end of the day the 
implementation can be changed if necessary. Since you are hoping to hack 
a solution together before me, it would make more sense for you to take 
the time working on the solution than replying to my points in this 
mail. I provide them only as further food for thought.

I wait with eager anticipation :-))


View raw message