forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [Proposal] New format for skinconf
Date Wed, 13 Apr 2005 15:02:48 GMT
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 :-)


I hope I find some time to catch up with the latest improvements in Forrest some 
time ...

> ...
>>> 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 but 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.
> Also IIUC this is not what it's about... that is sharing part of the 
> skinconf between many Forrest-based sites.
> 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.
>  - 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;

your ideas sound good but the question is: Where do the imported docs come from? 

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

this will become (already is) a need for your plugins and for Cocoon blocks.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message