I started putting in some information that would at least document the interfaces alot better based on what I saw on the list so far. I put
Each type of ProcessingNodeBuilder or ProcessingNode interface is nicely separated, and they do one thing and one thing well. I really don't have any issues with that at all.
The TreeBuilder interface is much less straightforward. It mixes the concerns of the meta information for the language type captured in the config file with a bunch of processing things. I think we should look at separating the interface into more logical units. That would help make it more understandable.
For instance, we have a TreeBuilder which represents the language. That is nice and good. However, IMO it has one responsibility: to create ProcessingNodeBuilders for a particular file. The root ProcessingNodeBuilder in turn should have the responsibility of creating the ProcessingTree. The ProcessingTree in turn is used directly to process requests.
So, in essence, we have a couple of roles here--which might even simplify the implementation a bit:
* TreeBuilder: Create a ProcessingNodeBuilder tree. (what goes on in the
implementation should not be exposed in the interface)
* RootProcessingNodeBuilder: Create a Processor (which is implemented by
the ProcessingNodes)
* Processor: The actual runtime system we use (the assembled sitemap so
to speak).Currently, it looks like there are implementation details exposed in the TreeBuilder, mixed with runtime details exposed for the processing node builders.
I dunno, though. Do we want the TreeBuilder to only expose an interface to get a particular Processor based on a URI??? I'm undecided.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
