Berin Loritsch wrote:
Based on the calls from the whole of Cocoon, the core Processor
Interface is:
interface Processor
{
InternalPipelineDescription buildPipeline(Environment env);
boolean process(Environment env);
}
Well if you are going to clean up Processor interface, why not go one step
further:
interface Processor {
PipelineDescription prepare(Environment env)
throws ProcessingException;
boolean process(PipelineDescription pd)
throws ProcessingException;
}
Notes:
* It should not be "Internal"PipelineDescription - as long as there no
any other pipeline descriptions.
* Before, buildPipeline() did one step in request processing,
while process() did both steps. It can be more clearly separated
into two methods, one for each step - prepare (or build) a pipeline,
and process (or execute) it.
Vadim
(Note: I would separate out the InternalPipelineDescription object into
its own class)
Who calls these methods?
* the core Cocoon object
* the CocoonWrapper object
* The BlocksManager(s) objects
The getContext() method is used by the BlockManager(s) objects and the
CocoonSourceResolver to identify the URL context we are resolving. I'd
lean towards a separate interface, but at this point I'm not completely
against it in the Processor interface. Although, I'm still thinking it
can be handled outside the Processor. See below about the
SourceResolver. I'm thinking the whole URI management should be done
externally to the Processor. The Processor implementation should be
blissfully unaware of where it is installed.
The only thing that needs the getComponentConfigurations() method is the
DefaultSitemapConfigurationHolder.
We need a new interface to support that contract. Not all processors
need to use that.
AFAICS, this method is to support SitemapConfigurable interface, which is
implemented only by auth-fw and in a "trick" (as javadoc says)
SitemapVariableHolder component. No sure how it can be tidied up.
The Pipeline implementations need a contract or an external mechanism to
get the SourceResolver corresponding to a Processor. In my oppinion,
the SourceResolver heirarchy should be handled outside the Processor
itself. That's my oppinion though.
The getRootProcessor() is called by the SitemapSource object--again, the
same processor to URL heirarchy should be managed in an external mechanism.
SourceResolver.getRootResolver() is probably what's really needed here.
Vadim
All the attribute methods (set/get/remove) are strictly TreeProcessor
specific. There is no real reason for them to be part of the core
Processor interface. I think we can safely move them without causing
issues. The only other time the Attribute method is used is in the Core
class to get an Interpreter--and we even ignore the language for now.
In what way is the Interpreter important to the Core? In fact it is not
even called outside of the implementing method.
