cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Changing Pipeline API
Date Wed, 13 Dec 2006 16:15:29 GMT
I'm working on making the Cocoon pipelines usable independent of the 
tree processor. This is good for getting towards a more layered and easy 
to understand architecture, for reusability of pipelines outside Cocoon 
and for being able to write sitemaps in pure Java (or scripting languages).

I have solved part of it without changing any APIs but an outstanding 
problem is that the o.a.c.components.pipeline.ProcessingPipeline depends 
on the concrete class o.a.c.pipeline.SitemapErrorHandler, which in turn 
is tightly connected to the TreeProcessor implementation.

My suggestion is to make SitemapErrorHandler an interface:

public interface SitemapErrorHandler {
  public boolean handleError(Exception e) throws Exception;
  public ProcessingPipeline prepareErrorPipeline(Exception e) throws 
Exception;
}

Currently the second method has the following signature in trunk:
public Processor.InternalPipelineDescription 
prepareErrorPipeline(Exception e) throws Exception;

But it has the suggested signature in 2.1.x, so it shouldn't be any 
problem to change it back.

There will be two implementations: the current one that will be moved to 
o.a.c.components.treeprocessor and a minimal one that will be usable in 
a pure Java sitemap (name suggestions are welcome ;) ).

There is not much point in starting a vote about it as the current 
ProcessingPipeline is nearly impossible to use outside the 
TreeProcessor, so the change will not break any applications.

Opinions, suggestions?

/Daniel






Mime
View raw message