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 Thu, 19 Sep 2002 12:24:35 GMT
<snip/>

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

Is it bragging when I claim that I was hoping you to say this :-)
in doubth about being nice to you or Konstatin now :-)

there is some advantage to the simplicity of having a simple 
props file read in by the inputmodule though...

the most important one I see is that writing the sitemap will not 
involve {forrest:some/nifty/xpath[hard-to-read(xpression)]/} but 
rather straightforward {forrest:property.key.name}

also the property-file impl could more easily be learnt to also 
work for System props (and thus support the cocoon.Main 
-Dskin=... example Jeff ended with)

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


Mime
View raw message