cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Fwd: Documenting the TreeBuilder stuff]
Date Tue, 28 Oct 2003 17:17:11 GMT
Berin Loritsch wrote:

> Sylvain Wallez wrote:
> 
>> Berin Loritsch wrote:
>>
>>
>> Sorry Berin, I don't clearly understand your concerns and how you what 
>> you want to move from TreeBuilder to RootProcessingNodeBuilder.
> 
> 
> The chief concern is breaking down exactly what the TreeBuilder is for,
> and having a set of interfaces/implementations that reflect that.  I 
> believe
> that it would simplify the migration, future enhancements of the system.
> 
>>
>> Also, I don't think we need an explicit ProcessingTree class. What 
>> will this class do that is different from a ProcessingNode?
> 
> 
> Essentially what I was thinking was this:
> 
> The TreeBuilder as it stands is too complicated, and it seems to mix the
> client concerns, internal use concerns, and processing concerns.
> 
> I would like to simplify it from a client perspective.  If I were to use
> the TreeBuilder, I would assume that the configuration provided by the
> container would point to all the <tree-builder/> definition files that
> are needed by the system.  From there we need a way for the TreeBuilder
> to access the proper.
> 

...  Sorry I hit the send button when I answered the phone on accident ...

... to access the proper generated processor.

THe thing is how would it be best to look up that processor?  Assuming we
have a Source for the particular Sitemap/whatevermap would we use that
to map it?  Probably.

Anyway, it is primarily the concern of only presenting to a client what
needs to be presented.  We can encapsulate the TreeBuilder instances
within the root processor.

What do you think?


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message