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. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
