You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/10/27 14:42:40 UTC
[Fwd: Documenting the TreeBuilder stuff]
I sent thisto the wrong place...
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [Fwd: Documenting the TreeBuilder stuff]
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: [Fwd: Documenting the TreeBuilder stuff]
Posted by Sylvain Wallez <sy...@apache.org>.
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.
Agree that it mixes client (TreeProcessor) and internal
(ProcessingNodeBuilder) concerns. But I don't see where it mixes
processing concerns, since processing is only handled by the
ProcessingNodes.
> 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 don't understand :-/
What are "all" the <tree-builder/> definition files? Do you mean
tree-processor-builtins.xml? Remember also that the "client" of the
TreeBuilder is only the TreeProcessor. Nobody else should need a
TreeBuilder.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Fwd: Documenting the TreeBuilder stuff]
Posted by Berin Loritsch <bl...@apache.org>.
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [Fwd: Documenting the TreeBuilder stuff]
Posted by Sylvain Wallez <sy...@apache.org>.
Berin Loritsch wrote:
> 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.
Sorry Berin, I don't clearly understand your concerns and how you what
you want to move from TreeBuilder to RootProcessingNodeBuilder.
Also, I don't think we need an explicit ProcessingTree class. What will
this class do that is different from a ProcessingNode?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com