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
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
