cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject The real Processor concerns
Date Tue, 11 Oct 2005 14:55:33 GMT
Based on the calls from the whole of Cocoon, the core Processor 
Interface is:

interface Processor
{
    InternalPipelineDescription buildPipeline(Environment env);
    boolean process(Environment env);
}

(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.

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.

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.


Mime
View raw message