cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: The real Processor concerns
Date Tue, 11 Oct 2005 15:48:34 GMT
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.

Mime
View raw message