cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] objectModel issues
Date Mon, 19 Mar 2001 04:22:09 GMT
Donald Ball wrote:
> 
> On Tue, 13 Mar 2001, Berin Loritsch wrote:
> 
> > One of the ideas behind Cocoon is the ability to use it in
> > different contexts like: JAMES Mailet, Servlet, Avalon Block,
> > CommandLine, etc.  One of the things that we do that makes
> > Cocoon inextricably tied to the Servlet API is the use of
> > the HttpServletRequest (or even HttpRequest) objects in
> > logicsheets, actions, and any place we want to get a request
> > parameter.  This is not consistent with the Separation of
> > Concerns pattern in use within Cocoon.  We have specified
> > several interfaces that allows Cocoon to abstract out the
> > interface from the implementation.
> >
> > What we have is a mess on our hands in this regard, because
> > it forces Cocoon to be a Servlet, and only a Servlet.  Cocoon
> > needs to specify the interfaces that it will allow internal
> > components to use.  If that means redefining the HttpServletX
> > interfaces to be Cocoon specific, then we need to do that.
> > It will also allow us to have the HttpServlet22 and HttpServlet23
> > classes in the archive at the same time.  That will allow the
> > webapp to be compiled once and deployed in any Servlet 2.2+
> > container--without recompiling.
> >
> > I would propose simplifying the Request/Response interfaces
> > a little bit, and merging the Parameters and Attributes into
> > one access point.  Also, by using this approach, we won't need
> > to worry about having the Servlet jar in the classpath.
> 
> it sounds good on paper, but i fear the devil in the details. are you
> thinking of providing, um, context-independent API's for request
> parameters, http headers, cookie stuff, and session stuff? or just request
> stuff?

That's part of the issue.  I really don't care if it's a wrapper class
around the Servlet interfaces.  We already have that--but I wanted those
wrapper classes to implement Cocoon interfaces, that allows new Environment
implementations.  We have a FileSystem Environment and a Servlet Environment.
I just want to complete the work that is already started.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message