Carsten Ziegeler schrieb:
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.
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).
Steven
Carsten
