cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [Corona] PIpeline API
Date Thu, 17 Jul 2008 14:22:26 GMT
Andreas Hartmann wrote:
 > <SNIP/>
> The DSL interpreter would use reflection to call the setStylesheet() and 
> setXsltParams() methods of the XsltTransformer. A resolver service would 
> be used for parameter expansion, e.g. for input module calls in Cocoon.
Yes, sure, reflection tricks could be used instead of course. This would 
also detect typos in the parameters as the according set method would 
not be available.

> About the first aspect:
> I don't think that the calling code has to know the actual components,
> but rather the environment-specific interfaces of the components. It
> only makes sense to pass an environment to a pipeline component if the
> component is designed to use this environment. 

 > Maybe I can try to come
> up with a more generic example:
> public interface WebappPipelineComponent extends PipelineComponent {
>   void setRequest(Request request);
> }
> Client code inside a web application:
> public void parameterizeComponents(Request req, Pipeline pipeline) {
>   for (Iterator i = pipeline.getComponents().iterator(); … ) {
>     PipelineComponent c = (PipelineComponent);
>     if (c instanceof WebappPipelineComponent) {
>       WebappPipelineComponent wpc = (…) c;
>       wpc.setRequest(req);
>     }
>   }
> }
> The pipeline is executed in a specific environment. The actual
> pipeline object itself is oblivious of the environment information, but
> the pipeline components are directly dependent on the environment.
Hmm, yes this would work, but :) this would make it harder to have a 
reusable pipeline implementation that frees my application from passing 
the information to the components.
Currently the app creates a map, passed it to the pipeline 
implementation and this implementation passes the map on to the components.
With the approach above, I would need a custom pipeline implementation 
to do this. Furthermore there might be a lot of marker interfaces to test.
Actually I'm not sure which approach is nicer :)


Carsten Ziegeler

View raw message