forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
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:41:54 GMT

Marc Portier wrote:
> 
> 
> 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 :-) ]

project.xml  is already used by Maven, we need a different one as 
explained in the other mail.

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

That's an idea.
I would prefere a JXPath input module that simply accesses the info in a 
JXPAthable object (xml DOM, javabeans, etc), just like the jxpath 
inputmodule for Ant embed does.
http://krysalis.org/cgi-bin/krywiki.pl?AntJXPath

> 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


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message