forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: No more @skin@ in sitemap (Re: cvs commit: xml-forrest/src/resources/conf cocoon.xconf sitemap.xmap)
Date Thu, 19 Sep 2002 11:32:44 GMT

Jeff Turner wrote:
> On Wed, Sep 18, 2002 at 09:47:08AM +0200, Marc Portier wrote:
>>Jeff Turner wrote:
>>>On Tue, Sep 17, 2002 at 05:10:55PM +0200, Marc Portier wrote:
>>>>- what does this tell about the somewhat promised "skinconf.xml"?
>>>skinconf.xml is just a bunch of declarative data about the user's
>>>project. It can be used to configure any skin. It doesn't specify which
>>these opening lines suggest the name for it should be 'bigger' 
>>then the current skinconf.xml
> You're meant to say "Egads! that sounds just like module.xml" ;P

Or properties.xml...

>>it doesn't need to be called siteplan.xml for me :-), but I do 
>>like systems where there is one clear location for all config 
>>stuff, just my 2c
>>in this vision: if there is more then one concern to be expressed 
>>there can be delegations to other files, but at least their 
>>locations should be managed centrally then
>><skinconf file="..." />
> Sounds good.
> I think we could distinguish between two types of configuration:
> 1) Passive, declarative, context-free data about the project, that
>    happens to be useful for configuring skins and whatnot. Ideally this
>    should all be in a file like modules.xml. 

see below...

>(OT: Nicola: modules.xml is
>    a dumb name; how about renaming to metadata.xml?)

We had the same discussion in centipede list, and basically we don't 
know how to call it best.

module.xml sucks for all, what do you all propose?
Maven called it project.xml, but for us it includes more projects, and I 
don't want name clashes.

All jakarta and xml projects that use it have called it gump.xml, but I 
still don't know for sure...


  - metadata.xml
  - info.xml
  - projectinfo.xml
  - gump.xml
  - nameofproject.xml

> 2) Config that says how I want _this_ run of Forrest to be done. Ie, skin
>    to apply, debug level, directory locations etc.
> (1) could be an enhanced modules.xml, delegating to external xml files to
> specify forrest-specific things like which DTDs are used.
> (2) could be

Honwstly ATM I have not put config data in module.xml yet because it's 
defined in properties.xml.

Now it's under tools/cents/forrest/*

> Do we need anything else?
>>>    class="org.apache.cocoon.components.modules.input.DefaultsMetaModule"
>>>    name="defaults">
>>> <input-module name="request"/> <!-- First use request params -->
>>> <input-module name="config"/>  <!-- .. Then fall back to config params

>>> -->
>>> <values>                       <!-- .. Otherwise use defaults -->
>>>   <skin>forrest-site</skin>
>>>   <base-url>/forrest</base-url>
>>>  </values>
>>>Umm. Slightly fictional but I don't see how else to fix the bot.
>>mmm, would it not be easier for the bot to generate the active 
>>skinconf.xml file based on the local skinconf and possibly 
>>overriding any variables in there with values supplied at 
>>(bot)-generation time
> But skinconf.xml does not select the skin, so auto-generating is won't do
> any good.
> A short-term fix to the problem would be to auto-generate cocoon.xconf,
> where the skin default is hardcoded.

Or use modules and have properties.xml add info about the configuration.

> ...
>>by the way: is the skinconf stuff already in cvs?
> Not yet.
>>I also had the impression that the ?skin=avalon-site wasn't 
>>really working on my generated webapp... What am I missing?
> Worked for me.. make sure you've got the new jars, new sitemap, new
> cocoon.xconf etc.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message