Vadim Gritsenko skrev:
Renaud Bruyeron wrote:
Therefore I would really like to be able to isolate the pipeline from
the rest of cocoon, and be able to configure and instantiate it alone.
I would like to do things like this:
Generator producer = MyFactory.newGenerate(...);
XMLConsumer consumer = MyFactory.newConsumer(...);
pipeline.generate(producer, consumer);
It is possible to use pipelines directly, it would look something like:
...setup container...
ProcessingPipeline pipeline = new [Non]CachingProcessingPipeline();
pipeline.enableLogging(...);
while (...) {
pipeline.setup(new Parameters());
// Pipeline will get generator from container
pipeline.setGenerator("file", ...);
pipeline.addTransformer("xslt", ...);
pipeline.setSerializer("html", ...);
Environment env = new BackgroundEnvironment(...);
pipeline.process(env);
pipeline.recycle();
}
I am willing to dig around in SVN, however it would help a lot with a
few pointers. I could not find anything beyond 2.1.x on the
wiki/official site.
Cocoon 2.2 (spring based) is in trunk, Cocoon 2.1 (avalon based) is in
branch.
Do you have any pointers to things I should look at in SVN, or even if
what I am asking for is remotely possible?
It might be more complex than what you want but it's possible.
If we want to factor out the pipeline functionality to an own block that
doesn't depend on the rest of Cocoon it will certainly be a lot of work.
But I think it would be worthwhile anyway as it would increase usability
and make the architecture easier to follow and maintain.
We should IMO strive towards a layered architecture where we have a
sitemap (treeprocessor) block that depends on a pipeline block. Where
the pipeline block contains the pipeline, pipeline components and the
environment as well as numerous classes supporting them.
Taking a look at the pipeline code there are some dependencies on that
would need to be removed. The ProcessingPipeline interface depends on
the class o.a.c.sitemap.SitemapErrorHandler that in turn depend on
treeprocessor stuff. It would be better to create an interface e.g.
PipelineErrorHandler that the ProcessingPipeline depends on.
There is also a Processor.InternalPipeline descriptor that is used for
the error handling within the pipeline implementations. It would IMO be
better to move this internal class from the Processor interface to the
components.pipeline package.
Both these changes affects interfaces, but I would be surprised if
anyone have implemented Processor or ProcessingPipeline outside our code
base, so it shouldn't matter that much.
The AbstractProcessingPipeline gets its SourceResolver through
EnvironmentHelper.getCurrentProcessor().getSourceResolver(), we need to
use dependency injection for it instead to make the implementation
easier to reuse outside the treeprocessor.
/Daniel
