Carsten Ziegeler skrev:
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.
We have had quite a few threads about our problems, so I'm not going to try to find our biggest problem in this thread ;)
But one of our problems is that core is monolitic and hard to understand. And this in turn depends on many small complexities that adds upp to overall complexity. One of these problems is th environment abstraction, and that is a problem that I happen to be motivated to atack now.
The reason for that is that I want to make the block architecture as independent of Cocoon specifics as possible. And I want to use servlet interfaces instead of our own, but this will require CLI to use servlet interfaces to be able to use blocks. So I wanted to know the communities thoughts about this.
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?
We can either ave an own extension or better have an extra interface that only contains the extension, then we can check if this extra interface is used in the code. Also we seem to be heading towards making controllers more of a first class citicen in Cocoon, and then we shouldn't force people to handle sitemap specifics in the new controllers.
And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2?
It depends on the timeframe for 2.2 ;) I will be offline for the next two weeks (kitesurfing in Mexico :) ) after that I would like to ditch the enviroment abstraction ASAP.
So it sounds like 2.2. /Daniel
