cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: question regarding the Cocoon 3 API
Date Sun, 17 Jul 2011 15:09:55 GMT
Am 15.07.2011 16:12, schrieb Reinhard Pötz:
> On 07/07/2011 12:09 PM, Robby Pelssers wrote:
>> Hi,
>>
>> Are my following assumptions right?
>>
>> -setConfiguration is typically used when using sitemap
>
> yes
>
>> -but for setup(params) method the API states that this is the shared map
>> for all components… so it should not be called directly
>>
>> but it gets indirectly called when executing
>> pipeline.setup(outputstream, params)?
>
> yes, see o.a.c.pipeline.AbstractPipeline#setupComponents
>
>> If it was not intended this way, then
>> https://issues.apache.org/jira/browse/COCOON3-68 applies.
>>
>> -But I still can see the need that different components need to be able
>> to be setup with different maps of parameters. Suppose both components
>> need a “id” parameter but for
>>
>> the generator this needs to be value ‘x’ and for e.g. the transformer
>> value ‘y’. Then using a shared map will not work.
>
> If you use the Java API directly, you can pass any parameter by using 
> the constructor or a custom setter method to your component.
>
> There should be no need to call the setup method yourself.
>
Exactly.
If you use the Pipeline API programmatically you should use the specific 
setters and getters of the pipeline and its components directly.
After all you add them to the pipeline yourself, so you have full 
control over the type and way they are constructed and should be able to 
use specific getters/setters.

The generic methods 'setup' and 'setConfiguration' are offered for 
enviroments that can not or do not want to use the specific 
setters/getters of the pipeline or its components.

Of course it is not possible to supply different values under the same 
key with the generic methods.
The question here should be: Why does my scenario require that?

The two obvious solutions to this are:
1) use different parameter names (one could argue that two different 
parameters must not have the same name when they can occur within the 
same context, otherwise this will result in ambiguity - which is exactly 
the problem here)
2) provide the parameters before adding the components to the pipeline 
(during construction), thereby avoiding having them in the same context 
and resolving the ambiguity


Mime
View raw message