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)
