forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.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 12:16:36 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
> 
> 
>>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?)
> 
[ OT: is project.xml taken ?
   I'ld prefer a name that says something about what the metadata
   is about, rather than that it is :-) ]

> 2) Config that says how I want _this_ run of Forrest to be done. Ie, skin
>    to apply, debug level, directory locations etc.
> 
yep

> 
> (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?
> 
not atm I guess

> 
>>><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.
> 
didn't catch that, sorry...

I was refering to your idea of having a skinconf oriented 
inputmodule (that's how these are called right?)

so maybe this remark just pushes for a different name for the 
beast then :-)

Could there be a this-run-modifying-config.xml (maybe a simple 
props file could suffice?) that is read in through these 
inputmodules? so we get to have some {forrest:skin}  inside the 
sitemap?

then you could give the -D or ant props (for conf file location 
or for actual prop-values) to the forrest.build.xml which would 
produce the required this-run-modifying-config.xml to be picked 
up by the sitemap?


> A short-term fix to the problem would be to auto-generate cocoon.xconf,
> where the skin default is hardcoded.
>
naah
the difference is subtle though...

> ...
> 
>>by the way: is the skinconf stuff already in cvs?
> 
> 
> Not yet.
> 

no pro, time is short atm but hope to take a closer look soon

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

I did the cvs update, must be overlooking something silly, have 
too little time atm to go in depth though

> 
> --Jeff
> 

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message