forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Forrest customization (was: partial skin overriding)
Date Sat, 27 Dec 2003 20:39:59 GMT
Dave Brondsema wrote:
> I still agree that in most cases partially overriding a skin is bad.  But here
> is a good use-case:
> Since many skins now use CSS (a *good* thing), it would be ideal for users to
> modify just the css file(s) to tweak the appearance of a standard skin.  

You are bringing up a very important part of the current changes I've 
done and still doing, so I'm very happy about it.

I agree with what you say, and add that it's not only about tweaking a 
skin but also *enhancing* it.

In fact, if we add a @class attribute to elements, users can easily 
customize Forrest the *right* way, by adding semantics with the class 
and visualization with the CSS, without using more complex things like xslt.

> Could this be solved with a matcher that looked in the project's skin directory
> for the requested file and if not found, then looked in the standard skin
> directory?  This would still prevent a custom skin from overriding stylesheets
> because the xsl:import would only look for files relative to itself.

IIRC I had already inserted a matcher to look in the common skin first...

What about adding the possibility to add a skins/user.css that every 
skin adds at the end of the CSSes?
In this way the user can change skin but keep the customizations.

In any case, this is part of what I'm going to do in these days.
Let me try to summarize and see what you think.

--- Forrest Customization ----

Forrest is loosly organized as MVC, where

  - model      -> 1 content
  - view       -> 2 style (skins)
  - controller -> 3 control (sitemaps + xslts)

I'm trying to make it easy to extend these parts indipendently.

For each point, here are the extensibility options in increasing difficulty.

1) a - locationmap
    b - @class attribute (thanks Ross :-)
    c - autodownload of DTDs
2) a - color schemes in skinconf.xml
    b - enhancing CSS
    c - autodownload of skins
3) a - autodownload of xslts
    b - autodownload of extra sitemaps

Where the autodownloads of 1 and 3 must be done together in a same 
package, as they are coupled.

Let me try and explain them separately.

1 - Content configuration

a) A problem we have now is how to specify where the content is. We 
cannot easily tell Forrest to download feeds from the web or even get 
files from two directories. The locationmap will make it easy to tell 
Forrest where the sources are.

- status: the locationmap code is done and inclusion is tabled in
           version 0.7

b) By making it possible to use a @class attribuite, content writers can 
easily add semantics to documents without changing the DTD. The style 
can be changed down the chain to accomadate for it. In any case if the 
extra CSS is not there the rendering will not break down but just use a 
subset of what the semantics can convey.

- status: go ROSS, go!

c) To accomodate extra DTDS, we now have to edit the sitemaps. Not good 
as far as compatibility with future Forrest releases goes. If we make it 
possible to download DTD packages with corresponding xslts, we can make 
Forrest use them just by using simple naming convensions (ie the xslt 
filename is somewhere in the private id of the DTD)

- status: TBD, assigned to nicolaken

2 - Style configuration

a) color schemes in skinconf.xml

This is what I'm going to do now: make it possible to decide what colors 
to use in the skin directly in skinconf.xml

This makes it possible to then use these in the skin without editing 
CSS, that can easily be skin specific. In this way we can change skin 
but keep color profile.

Problem: the colors are in CSS. Thus I need to generate CSS by giving it 
values from skinconf.


  - use velocity and put skinconf in the context
  - use JXTemplate Generator and put skinconf in the context
  - generate it from the skinconf.xml and insert the CSS in an xslt

Since CSS is textual, the first option is the correct one, but we are 
addin another (albeit small) dependency...

- status: TBD, assigned to nicolaken

b) enhancing CSS

Where should we add the user CSS? What about skins/user.css?
In this way the user can change skin but keep the customizations.

- status: TBD, assigned to nicolaken

c) autodownload of skins

- status: DONE, needs testing

3 - control configuration

The extra xslts download is part of the DTD extenstions. As for extra 
sitemaps, I'm not ready to table it yet, but if someone wants to work on 
it, Cocoon now has configurable insertions of subsitemaps.


Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message