Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] 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
