Andreas Hartmann schrieb:
Carsten Ziegeler schrieb:
Bertrand Delacretaz wrote:
On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez <[EMAIL PROTECTED]>
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) i.next();
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.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
