cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Change of the Environment abstraction
Date Thu, 03 Aug 2000 12:34:34 GMT
Hi all

I still was in doubt if my implementation of the environmetn abstraction
was as supposed to be mentioned by Ricardo. I've talked to him and we
discussed what was missing. So I would like to introduce the folllowing
changes (mostly suggested by Ricardo, our magician :) to the
implementation.

We would like to extending the current Environment interface as follows:

  public interface Environment extends EntityResolver {
    // Sitemap methods
    public String getUri (); 
    public void changeContext (String uriprefix, String context) 
        throws MalformedURLException;

    // Request methods
    public String getView ();

    // Response methods
    public void setContentType (String mimeType); 
    public OutputStream getOutputStream() throws IOException; // NEW

    // Object model
    public Dictionary getObjectModel(); // NEW
  }

We add:

  public Dictionary getObjectModel();

to the Environment interface. Given this, we can easily support
"regular" servlet programming by defining a ServletGenerator like:

  public abstract class ServletGenerator extends ComposerGenerator {
    protected HttpServletRequest request;
    protected HttpServletResponse response;
    protected ServletContext context;
    . . .
    public void setup(Environment env, String src, Parameters par) {
      super.setup(env, src, par);
      Dictionary servletModel = env.getObjectModel();
      this.request = (HttpServletRequest) servletModel.get("request");
      // "response" is trimmed down by HttpEnvironment to hide "out"
      this.response = (HttpServletResponse)
servletModel.get("response");
      this.context = (ServletContext) servletModel.get("context");
      . . .
    }
  }

and have for example ServerPagesGenerator extend this class so that XSP
pages have transparent access to the servlet object model pretty much
like they do today in Cocoon1.

What changes?

1. The output stream is a property of the calling environment and should
   be made available only through it (as opposed to a separate argument
   as seen in the current implementation of Cocoon.process(),
   SitemapManager.invoke() or sitemapHandler.process()).

   For HttpEnvironment, this would be implemented simply as:

     public OutputStream getOutputStream() throws IOException {
       return this.res.getOutputStream();
     }

2. As a consequence, the [environment] HttpResponse.getOutputStream()
   and HttpResponse.getWriter() methods need not worry whether they've
   been called by a Serializer or a Reader. Instead, they should simply
   throw an IllegalStateException: no Cocoon object should (ever!) need
   access to the _servlet_ output stream. Readers and Serializers should
   be passed only the output stream explicitly provided by the
   environment.

3. Every Environment has an associated object model expressed as a
   collection of named objects whose names and types vary from
   environment to environment. Instead of defining environment-specific
   get[Object]() methods, it's more general to define a higher-level
   Environment.getObjectModel() method that returns a Dictionary of
   objects making up the model.

   For this, HttpEnvironment could be extended as follows:

      /** The object model */
      private Dictionary objectModel = null;

    /**
     * Constructs a HttpEnvironment object from a HttpServletRequest 
     * and HttpServletResponse objects
     */
    public HttpEnvironment (String uri, HttpServletRequest req, 
                            HttpServletResponse res, 
                            ServletContext servletContext) 
    throws MalformedURLException {
      this.uri = uri;
      this.view = req.getHeader("cocoon-view");
      this.req = new HttpRequest (req, this);
      this.res = new HttpResponse (res);
      this.servletContext = servletContext; 
      this.context =
        new URL("file://"+servletContext.getRealPath("/"));
      // Object model
      this.objectModel = new Hashtable();
      this.objectModel.put("request", this.req);
      this.objectModel.put("response", this.res);
      this.objectModel.put("context", this.servletContext);
    }

    /** Return the servlet object model */
    public Dictionary getObjectModel() {
      return this.objectModel;
    }

4. As stated above, an abstract ServletGenerator class
   could extend ComposerGenerator to cast back the servlet objects
   to their "true" types and make them transparently accessible to
   derived classes (such as ServerPagesGenerator)
    
What's your opinion?

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message