Daniel Fagerstrom wrote:
No, I meant something different than the mechanism today, something
that works like the PropertyOverrideConfigurer in Spring. Say that you
have a configuration file like:
<store logger="core.store">
<parameter name="maxobjects" value="1000"/>
<parameter name="use-cache-directory" value="true"/>
</store>
Then my idea was that you should be able to override the maxobjects
property by just providing a property:
store.maxobjects=2000
The mechanism of today is more like the PropertyPlaceholderConfigurer
in Spring and would require you to rewrite the configuration file like:
<store logger="core.store">
<parameter name="maxobjects" value="${store.maxobjects}"/>
<parameter name="use-cache-directory"
value="${store.use-cache-directory}"/>
</store>
and provide default property files for all properties.
Oh, OK. But we also support
<component-instance name="javascript"
class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter">
<load-on-startup>resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js</load-on-startup>
<reload-scripts>${javascript.reload-scripts}</reload-scripts>
<check-time>${javascript.check-time}</check-time>
</component-instance>
Would this be replaced by
javascript.reload-scripts = true
i.e., How does it know when to look for attributes versus the value of
child elements? Or would it just assume you won't have an attribute with
the same name as a child element?
I'm actually surprised that the syntax for your example isn't
store.parameter.maxobjects = 2000.
But I've never looked into this feature in Spring.
Ralph
