forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [Proposal] New format for skinconf
Date Wed, 13 Apr 2005 07:34:24 GMT
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!

> The Cocoon project has the need for many repositories in the future. We will 
> split our codebase in many blocks and each block will become as independant as 
> possible. This is also valid for the documentation with the reuslt that we get 
> many Forrest repos.

Actually we will do the same in regards with plugins. A plugin is
comparable to a cocoon block. It is aimed to be independent from the
core and having their own documentation.

> 
> 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 (see 
> http://svn.apache.org/repos/asf/cocoon/trunk/src/documentation/src/skinconf.xml) 
>   and svn:externals to merge content+project_specific_information with Cocoon 
> wide styling information (CSS, custom sitemap). This solved my problem (for now).
> 

I had a look and it is a very elegant solution. 

> I haven't had a look at plugins yet (sorry, I'm still using Forrest 0.6) - if 
> you tell me that the use of them will solve my problem in the future, just 
> forget this request - otherwise I would be interested in discussing the Forrest 
> and properties topic with you.
> 

Thanks Reinhard to speak up and bring back a point that we discussed a
while ago.

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

The view concept is pretty new and will go as snapshot into 0.7 and will
be the default skinning engine in 0.8. The concept is using the idea of
fallbacks. If you do not need a specific view on your project the
globally defined properties will be used.

That leads us to the question which components should be split apart
from the skinconf that we are using right now. Arik already pointed out
(like yourself) that the color scheme should go into a file for its
own. 

...but there are many more components that we define in skinconf but IMO
belong in a view config. e.g. feedback, trail, ...

Splitting them apart makes it possible to easily use the fallback
mechanism. If a block do not define block view specific properties the
default properties will be used. I reckon there are only a couple of
properties that need to be overridden by a block. The majority of
properties will be used from the default view config from cocoon
directly.

Having said all this it makes me thinking whether or not we should keep
the skinconf or better rename it (to viewConf.xml) and split it in
different files (e.g. regarding colors colorConfCocoon.xml,
colorConfLenya.xml, ...)

Like I stated above your solution of entities is very elegant way but it
is still a workaround and we should provide a mechanism to overcome
this.

Cheers for sharing your thoughts here in this list.

p.s.: You may want to change (of the above given link) to
cocoon.apache.org. ;-)
<search name="Apache Forrest" domain="forrest.apache.org"
provider="google"/>

salu2
-- 
thorsten

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


Mime
View raw message