cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <>
Subject Re: [Corona] PIpeline API
Date Wed, 16 Jul 2008 15:58:17 GMT
Carsten Ziegeler schrieb:
> Andreas Hartmann schrieb:
>> Carsten Ziegeler schrieb:
>>> Bertrand Delacretaz wrote:
>>>> On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez 
>>>> <> wrote:
>>>>> ...Can't we just give the parameters they need
>>>>> individually to every pipeline component, thus allowing per-component
>>>>> strongly typed and well defined contracts?..
>>>> I'm also catching up on this thread but I tend to agree with the above
>>>> suggestion, i.e. something like
>>>>   Transformer t = new XsltTransformer();
>>>>   t.setXslt("cocoon:/mytransform.xsl");
>>>>   t.setRequestParameters(request.getParameterMap());
>>>>   ...
>>> Ok, in this case you can't use "Transformer" as the class type. This 
>>> would be:
>>> XsltTransformer t = ...
>>> Now, it seems that we are still mixing up things here. As I said, 
>>> I'm not talking about configuration of the components. The 
>>> stylesheet from above is a configuration.
>>> We're talking about information about the current environment for 
>>> executing the already configured pipeline.
>> IIUC the request parameters in the above example would belong to the 
>> execution environment, wouldn't they?
>> I'd imagine something like this:
>> public void parameterizeTransformers(Request req, Pipeline pipeline) {
>>   for (Iterator i = pipeline.getTransformers().iterator(); … ) {
>>     Transformer t = (Transformer);
>>     if (t instanceof WebappXsltTransformer) {
>>       WebappXsltTransformer xsltTr = (WebappXsltTransformer) t;
>>       if (xsltTr.useRequestParameters()) {
>>         xsltTr.setXsltParams(req.getParameterMap());
>>       }
>>     }
>>   }
>> }
> Now all these examples assume that the calling code knows the components.
> For my use case - and it's the same with the Cocoon sitemap - I've a
> description of a pipeline (think of the sitemap) which has just the name
> of the pipeline components to chain. A generic code instantiates these
> pipeline components - through a service registry - and does not know 
> anything about these components apart from the fact that they are 
> pipeline components.
I completely agree here.
Specific situations might allow specific solutions, e.g. providing 
listeners/callbacks while creating the individual components.
However a more general solution that also supports more general 
scenarios like the one described above (components are created by a 
service/factory/etc.) should also be available.

I wouldn't mind having a general purpose setup/teardown (or 
preExecution/postExecution, etc.) method defined and called by the 
pipeline API itself.
Might not be a good example, but JUnit provides such methods for unit 
tests and does not delegate this to another framework/container that 
might or might not be available, since this is a genuine requirement for 
certain tasks to be solved with the framework.

However the listener approach also appears to be appealing to me. 
Although I'm not entirely sure this would be as easy to use as the 
lifecycle methods proposed before (especially when a pipeline is built 
by the sitemap engine or service/factory).

> Carsten

View raw message