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 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.
...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 files. > - 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). salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
