cocoon-dev mailing list archives

Hi Carsten,
Carsten Ziegeler schrieb:
[…]
>> 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.
Maybe we have to differentiate between two aspects of execution environment:
1) Information that is not contained in the pipeline description, e.g.
the request in a web application
2) Parameters which are part of the pipeline description DSL (like
<map:parameter/> in Cocoon)
The second aspect could be handled by the pipeline DSL interpreter in a
generic way. I imagine something like this:
match wildcard(pattern: "*") :
generate xml(uri: "context://{1}.xml") >
transform xslt(stylesheet: "{request-param:style}", xsltParams: …) >
serialize xml;
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.
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) i.next();
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.
You gave this example in a subsequent mail:
String type = // the component type
Map m = // the execution information
Transformer t = springContext.getBean(type);
t.setup(m);
IIUC this code would be part of the "pipeline executor" implementation.
I assume that m only contains information in the sense of aspect 1
described above, because the DSL params wouldn't have to be passed to
the pipeline. If this is the case, there has to be client code like this:
Map m = new HashMap();
m.put("request", this.request);
pipelineExecutor.setEnvironment(m);
Passing the environment to the pipeline is only necessary if there might
be some pipeline components which could be interested in the request
object. Wouldn't it then make sense to pass this information directly to
these components, like in the parameterizeComponents() method above?
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01