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 13:27:56 GMT
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.

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


Mime
View raw message