cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: Request Interface
Date Wed, 24 May 2000 16:18:51 GMT
Marcelo Ochoa wrote:
>         I´m writing a new generator for Cocoon 2 to implement Prism DBProducers of the
previous version. I found that the Request interface encapsulate the HTTPServletRequest parameter
of Servlet. This interface has methods to retrieve arguments, however I can not find a method
to retrieve the request object.
>         Prism needs the complete request inside the code. Otherwise, I must re-implement
a lot of code that make not sense. It is possible to incorporate a new method called, for
example, getRequest which returns the HttpServletRequest object?. It can be located in the
interface or in the implementation class called CocoonServletRequest.

Yes, Marcelo, this is something I've faced as well while
developing XSP.

Of course, no one wants to go back to the dark ages when
Cocoon was tied to its containing servlet environment, :-)

Currently, the Cocoon component exposes a "process"
method that takes as arguments a (Cocoon) request/reponse

This could be extended to accommodate as 3rd argument an
instance of an interface encapsulating the object model
of the calling environment.

Thus, for a servlet environment, this object would make
available the collection of familiar servlet objects:
servlet config, servlet context, "true" (i.e. Http) request
and response, etc.

Now, this goes beyond just making available a handy
collection of parameters (for which something like a
Dictionary would probably suffice).

Generators may need to interact with Cocoon/Sitemap based on
the result of operations performed on the calling environment
objects. This interaction has the potential to disrupt the
processing pipeline _statically_ specified in the sitemap.

Thus, for example, a call to response.sendRedirect() in a
generator (not an unlike event in server pages programming)
would require the sitemap to stop further filtering and
yield control back to the calling servlet environment.

Now, if redirection targets another Cocoon generator, the
sitemap could adjust is processing pipeline accordingly. If
it doesn't, the calling servlet engine should process the

Other operations, like writing to the servlet output stream,
have the potential to disrupt Cocoon's request handling in
unpredictable ways and are rightly discouraged.

We need to draw the line, yes, but we need to give more
thought to the way generators interact with the calling
environment and as well as with the sitemap processor.

Is it possible to allow this interaction to take place
in a safe and _container-independent_ way? I'm convinced
it is.

Let's work this out...

View raw message