cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Duffin <>
Subject General questions on design
Date Thu, 28 Nov 2002 12:17:04 GMT
I have some general questions on the design, the answer to many of them 
may be that it is historical but I could not find anything in the code 
to indicate this.

Please do not take these questions as criticisms, I am simply trying to 
understand the design of the code. If there is a resource that provides 
this level of detail then please could you refer me to it.

     Why does the SitemapModelComponent setup method not take an
     Environment object instead of the SourceResolver ?
         If this is historical then is it safe to always cast the
         SourceResolver to an Environment ?

     Why is the objectModel simply a Map ?
         It seems to me as though the code could benefit from providing
         an objectModel abstraction (which could itself just be a Map).
         It would certainly make it easier to track it through the code.

     What is the objectModel for anyway, why is the information that it
     contains not stored in the Environment ?
         The Environment seems to me as the perfect place to add the
         information in the objectModel.

     Why does the HttpEnvironment not provide methods to get access to
     the HttpServletRequest/Response and ServletContext ?
         If it did then I could simply cast the Environment to an
         HttpEnvironment and use type safe methods to get it out. As it
         stands I have to retrieve each part from the objectModel
         and cast it individually.

     Why does the CocoonComponentManager not provide methods to retrieve
     the information about the current environment ?
         As far as I can see this class manages the current Environment
         but does not provide access to it.

     As I understand it the AbstractEventPipeline does not contain a
     serializer so that its output can be directed to another pipeline
     but if that is the case why does it include a generator ?
         Having a generator in the AbstractEventPipeline surely makes it
         awkward to direct the output from one pipeline into another.

     How are errors handled ?
         If one part of the pipeline causes an error is there a way to
         recover from it ?

     Why does an XMLConsumer implement LexicalHandler ?
         Do you consider comments and CDATA sections significant in the
         pipeline ?

     Why does the XMLConsumer not implement ErrorHandler ?
         The Cocoon pipeline is obviously geared to creating xml
         documents for publishing on the web via the Serializer but it
         could also be used to create XML documents for an application.
         In the former case the ErrorHandler is probably not needed but
         in the latter it is.

To unsubscribe, e-mail:
For additional commands, email:

View raw message