cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: svn commit: r575768 - in /cocoon/trunk: blocks/cocoon-template/cocoon-template-impl/src/test/resources/org/apache/cocoon/template/jxtg/ core/cocoon-core/src/test/resources/org/apache/cocoon/components/treeprocessor/variables/ core/cocoon-expression-lan...
Date Sun, 16 Sep 2007 13:21:30 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> I'm not so happy about "non local" use of abstract bean configurations.
>> AFAICS it doesn't work with spring-osgi where you have one application
>> context for each block. And there is no obvious way to export abstract
>> configurations between bundles. Also they make the configurations harder
>> to read and, IMO, unnecessarily abstract.
>>
>> I think that abstract bean configurations are OK, as far as they only
>> are used within the configuation file where they are defined. Otherwise
>> I prefer beeing a litle bit more verbose. And one can always use factory
>> beans and custom configurations for complicated configuration patterns.
> 
> Your arguments seems to be valid. I'll take them into account when creating new code.
> 
> What about integration tests? Can I use configuration templates, there?

I would restrict the use of configuration to use within the same module. 
So it depends.

>>>> I also wonder
>>>> why you use camel case names for Spring config files instead of
>>>> following the name convention that all the rest of the Spring configs in
>>>> Cocoon use.
>>> I didn't know we have such convention; so what are the rules?
>> First, all configuration files are prefixed with the module name. This
>> is because they are collected from the classpath
>> (classpath*:META-INF/cocoon/spring somwhere in the configurator code),
>> to a common global Spring application context. Because of that the file
>> names needs to be unique.
>>
>> Second, smallcaps and hyphens are used. E.g. cocoon-core-generators.xml.
> 
> I see. Last question is about multiple bean declarations in one xml file. Do we think
it's good or
> bad practise?

No strong opinion about that. If a couple of beans works togther or are 
of the same "kind" it seem natural to put them together in one file. 
Otherwise not. What is your opinion?

/Daniel


Mime
View raw message