cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [C2] objectModel issues
Date Mon, 19 Mar 2001 13:49:10 GMT
Quoting Berin Loritsch <bloritsch@apache.org>:

> Giacomo Pati wrote:
> > 
> > Berin Loritsch wrote:
> > >
> > > 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.
> > 
> > In summer 2000 Stefano, Ricardo and I were talking about it at
> Stefano's
> > house. We've choosen to use the Servlet API as a base because 80%+ of
> > C2's use will be as a servlet. But you are right we ended up with
> > wrappers because we had to protect ourselfs from using harmfull
> methods
> > like messing with the output stream. And we further need to intercept
> > method
> > calls like sendRedirect to signal "end of production" to the
> > ResourcePipeline. As with the Servlet spec. 2.3 it started to get
> > complicated because of the need to extend the Wrapper classes supposed
> > to be
> > according to the spec. (at those times redirecting in Catalina wasn't
> > working if
> > your Response object wasn't derived from ResponseWrapper).
> > 
> > If I understand you correct you're proposing to consolidate all the
> > Request/Response wrappers we have so far into Cocoon interfaces for
> > Request and Response as base for all Environments C2 can work in,
> right?
> 
> Yup.  Even if the Cocoon interface is the same as the Servlet interface,
> and we use a wrapper that extends ServletWrapper and implements the
> Cocoon
> interface, all is well in the world.  We no longer would need to compile
> against the HttpServletRequest/Response classes--so that jar won't be
> needed
> in the "extra-classpath" init param.  We would have a basis for working
> on the CommandLine classes.

Ok, this sounds like a plan. Any volunteer?

Giacomo

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

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


Mime
View raw message