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