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 12:33:16 GMT

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

{forrest:property/key/name}

Which is xpath. It all depends on what you want to read.

{forrest:property/key/name/@attr}
{forrest:property/key/name[@attr='isitthere']/@attr}

This is usually as hard as it can get.

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

Ok, put it on the list that system properties can override defined ones.

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


Mime
View raw message