cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Ditching the environment abstraction
Date Tue, 13 Dec 2005 17:21:13 GMT
Leszek Gawron schrieb:
> Carsten Ziegeler wrote:
>>In general I agree with this - it makes learning Cocoon internal a
>>little bit easier. But I think the current environment api is not our
>>biggest problem. Anyways, our current Request object has more
>>functionality as the servlet request object, e.g. to get the sitemap
>>prefix and sitemap uri and more important the request attribute handling
>>for internal requests. How can we keep this functionality when switching
>>to the servlet api?
> Moreover we have just introduced Session.getAttributes, 
> Request.getParamters and so on. There are no equivalents in pure HTTP 
> interfaces.
Yepp, I actually thought about this last night and I think now, we
should not ditch this abstraction. If we would ditch it, we have to cope
with two problems: compatibility (noone wants to rewrite all of the
code) and additional functions (which are used throughout Cocoon).
Now, we could solve both problems by extending the servlet apis, but
then we still use our own interfaces in the end and nothing changes.

I did several Cocoon development training courses in the last years and
I think our own abstraction by itself was never the problem. The big
problem most times is, that people do not know/see that we actually have
a request object and how they can obtain it in there own code. If you
compare our pipeline component interfaces with interfaces from other web
frameworks there is an obvious difference: other frameworks/specs
(servlets, portlets etc.) always have a request and response object
directly in the signature of a method. So it's directly visible.
Our components have a map called object model and everything is hidden
in this map. So, I think changing this would be much more helpful for
newbies. They directly see a request/response object somewhere and than
it's obvious how to use them no matter what the package of that object is.
Now, basically another problem we have which is somehow related to this
is that our components get pooled. I think if we would switch to a
factory based approach for sitemap components (like we discussed and
already started), we could change the interface for those factories and
directly path the request/response object into them. I have the hope
that this will decrease the learning curve in this area.


Carsten Ziegeler - Open Source Group, S&N AG

View raw message