forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [Proposal] New format for skinconf
Date Wed, 13 Apr 2005 12:27:27 GMT
On Wed, 2005-04-13 at 13:42 +0200, Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> > On Wed, 2005-04-13 at 08:20 +0200, Reinhard Poetz wrote:
> > 
> >>[Sorry if I completly miss the point but as skinconf bothered me some hours a

> >>few weeks ago I can't resist on commenting on this]
> > 
> > :) Cheers for your comments, you hit the nail on the head!
> Concur. It's very nice to hear from you here :-)
> ...
> >>So far this isn't really difficult. But, it becomes interesting if you want to

> >>have all those repos having the same look without manually copy files around
> >>this is a problem as skinconf contains project specific information and 
> >>information how the final docs are styled.
> >>
> >>I ended up in using XML entities 
> IIUC it's about sharing the skinconf between projects.
> >>I haven't had a look at plugins yet (sorry, I'm still using Forrest 0.6) - if

> ...
> > I share your opinion that in the current skinconf we are mixing project
> > specific information and look & feel. That was one point to start the
> > discussion again.
> > 
> > Having your link in mind we have 
> >   &heading; 
> >   &extracss;
> >   &colors;
> >   &pdf;
> >   &credits;
> > 
> > as common components. IMO this components should be defined in a global
> > file. Besides this global file we can have view specific configuration.
> > I personally see the cocoon blocks a specific view on the cocoon
> > project(documentation). 
> It seems that the separation that you are proposing is more theorical 
> than practical, as it does not solve an actual need.

...right now I have not implement it that's why it is theoretical but I
am SURE that is as well practical. ;-)

Hmm, lets compare your solution with mine. 

> Also IIUC this is not what it's about... that is sharing part of the 
> skinconf between many Forrest-based sites.

Yeah, if you define a default (global) skinconf where you keep all the
default values then there is no need for forrest-based sites to even
have one. They will use the fall-back skinconf that you will have to
define for them.

> Instead, I would concentrate on one or more of the following:
>   - having a sort of "import" of the values of another skinconf, as 
> Ant's <import>. In this way a skinconf can use the values from another 
> one, and add or redefine just the values it needs.

Ok, I am talking about the same, only that I prefer to split the
properties of skinconf in different files and then only override this

>   - making a skin have a default skinconf that can be overridden: in 
> this way, all Apache could have an Apache skin with the copyright 
> already set, and a consistent look;

Hmm, in 0.8 we will not have the traditional skins that we have right
now. They become views based on contracts. This contracts can be written
the way you just suggested. Create a default copyright contract that can
be used apache wide.

...BUT I would not suggest to keep it in the skinconf. The skinconf is
to inflexible due to the fact that it is configuring the WHOLE site and
not only on a per page/document base. What would you do when you have a
one page or a couple of pages with different copyright notices?

>   - making it possible to render in a single site many subsites together.

That is IMO another problem and has no direct connection with the
skinconf. ...but thinking about it a little bit more, the view concept
let you have different "skinned" pages (or subsites) within on project
(if you talking about that).


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

View raw message