cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Ditching the environment abstraction
Date Tue, 13 Dec 2005 21:53:40 GMT
Carsten Ziegeler wrote:
> Ralph Goers wrote:
>> Daniel Fagerstrom wrote:
>>> The servlet set of apis is allready an abstraction, we have due to 
>>> historical circumstances another abstraction of the same concepts. To 
>>> me the abstractions look fairly similar, except for the Cocoon 
>>> aditions that have been mentioned. What am I missing more specifically?
>> What exactly are the sevlet apis an abstraction of? 
>>> We could have compablity wrapper. Question is do we want to simplify 
>>> or not?
>> What, exactly are we simplifying?  There is no way that we won't always 
>> have a "real" HttpServletRequest.  AFAICS there is no way that we can 
>> just use it.  So what would replace the existing Request object?  In 
>> order to understand this I really need to know exactly what the new 
>> object would be.
> Hmm, now, one possible way of simplifying could be to extend the
> HttpServletRequest/Response objects, so if you need an
> HttpServletRequest somewhere you directly have it. But for example our
> Response object does not provide access to the outputstream, and I'm
> sure even if we extend the HttpServletResponse interface, we want to
> block direct access to the output stream (by throwing an exception).

We _need_ direct access to the output stream. Ajax applications require 
to move away from the request/page-response paradigm that prevailed up 
to now. The controller must be able to send a direct response to the 
client for empty control responses or raw data.

CForms required this for to handle the end of the form interaction in 
Ajax mode, and I directly accessed the HttpServletRequest for this, how 
heretic it might seem :-)

> And there might be other examples for this - so in the end if you need a
> real servlet response object you can't use our response object as we
> block some operations.
> Currently, we store the original http servlet request/response objects
> in the object map next to our own versions of it. So if you really need
> the original objects, you can look them up.

Which makes actually two different abstractions for the same purpose, 
and makes blocking the outputstream on our own abstraction useless, as 
people can access it anyway.

It would be better IMO to have a single abstraction, but _control_ how 
the outputstream is used, e.g. by allowing it to be fetched only once.

> I have the feeling that changing this does not buy us something and that
> does it not make life easier - I might be wrong though. Now, I still
> think we should make the request/response objects more easily accessible
> somehow.

Yup. Now changing these abstractions aren't for Cocoon 2.2 IMO.


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message