forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: No more @skin@ in sitemap (Re: cvs commit: xml-forrest/src/resources/conf cocoon.xconf sitemap.xmap)
Date Wed, 18 Sep 2002 08:25:28 GMT
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

> 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
> 
> forrestconfig.xml
> <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. (OT: Nicola: modules.xml is
   a dumb name; how about renaming to metadata.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 forrest.properties

Do we need anything else?

> ><component-instance
> >     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>
> ></component-instance>
> >
> >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.

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


--Jeff

Mime
View raw message