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.
Agreed.
> 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.
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
--
Carsten Ziegeler
[EMAIL PROTECTED]
