cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/reading ResourceReader.java
Date Wed, 04 Feb 2004 16:01:58 GMT
Vadim Gritsenko wrote:

> Carsten Ziegeler wrote:
>
>> Vadim Gritsenko wrote:
>>  
>>
>>> cziegeler@apache.org wrote:
>>>
>>>   
>>>
>>>> @@ -143,8 +137,57 @@
>>>>      logger="sitemap.reader.resource"      pool-max="32" 
>>>> pool-min="1" pool-grow="4"/>
>>>>      <!-- optional reader configuration -->
>>>> -    <map:parameter name="expires" value="86400000"/>
>>>> +    <parameter name="expires" value="86400000"/>
>>>>    </map:readers>
>>>>
>>>>
>>>>     
>>>
>> The old doc was simply wrong. The original author confused pipeline
>> usage with component configuration.
>>
>>  
>>
>>> Why not map:parameter here for consistency sake, like in:
>>>    <map:matcher name="mount-table" 
>>> src="org.apache.cocoon.matching.MountTableMatcher">
>>>      <map:parameter name="ignore-missing-tables" value="true"/>
>>>    </map:matcher>
>>>   
>>
>>
>>
>> This would be the first component that uses the sitemap namespace
>> for the configuration.
>>  
>>
>
> Ummm... Why matcher can use map:parameter and reader can not?
>
>
>
>>> And more general observation: Should we prefer configure(), or 
>>> parameterize()? Currently, some sitemap components use parameters, 
>>> and the rest - configuration:
>>>
>>> (48 matches in Cocoon codebase, including non-sitemap components)
>>>
>>> Classes implementing configure():
>>>    Sendmail
>>>    SectionCutterAction
>>>    AbstractControllerAction
>>>    HttpHeaderAction
>>>    InputModuleAction
>>>    LocaleAction
>>>    PropagatorAction
>>>    ...
>>> (161 matches in Cocoon codebase, lots of them are sitemap components)
>>>
>>>   
>>
>> Ok, to be honest, I don't know which way is the best. In general using
>> parameters is imho the better looking solution, but that's only my
>> personal opinion.
>>
>> Now, we shouldn't change the configuration of existing components, 
>> but we
>> could (if we want) establish a guideline for new components. I choose
>> my prefered way for the reader. But we can change this to whatever the
>> majaority thinks.
>>  
>>
>
> Guideline would be good! Anybody else has opinion?


Yep. <map:parameter> within <map:match> is an instruction of the sitemap 
language, independent of the actual matcher (or reader, generator, etc) 
used, whereas <parameter> inside a <map:reader> is the component's 
configuration, which is dependent on the component and is not used by 
the sitemap engine.

The choice between Parameterizable/Configurable mainly depends on 
whether the component's configuration is flat or hierarchical. When the 
configuration is flat, Parameters are more easy to use and therefore 
Parameterizable is there as a convenience.

However, I'm happy to see this subject coming on the table, as I always 
disliked the fact that there's an important syntactic difference between 
Parameterizable and Configurable:
- firstly, this doesn't look consistent from the reader's POV, which 
doesn't have to know/care about this implementation detail.
- secondly, consider a component that evolves and needs to change from a 
flat config to a hierarchical config. Traversing <parameter name="foo" 
value="bar"> using a Configuration object becomes a real PITA.

So what I would love, is that Parameters.fromConfiguration() accepts 
<foo>bar</foo> along with <parameter name="foo" value="bar"/>

But this is a change to Avalon framework...

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message