cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Ditching the environment abstraction
Date Tue, 13 Dec 2005 19:57:49 GMT
Carsten Ziegeler skrev:
> 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 
> 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.

In the recent discussions many people want to see controllers as first 
class citicens in Cocoon, so that we can use flowscript or javaflow as 
the main controller, that calls the sitemap controller in turn. Also we 
need room to start experimenting with new controllers, as the 
"convention" controller that Berin started to work on.

The blocks architecture allready contains two new controllers: a block 
dispatch controller that is the main controller and take care of mounted 
  blocks and delegate the controll to a block controller that represents 
a particular block. The block controller in turn calls a sitemap controller.

Now I would like to generalise this so that the block controller can be 
configured to dispatch to any controller not just  be hard wired to the 
sitemap controller.

Also I would like to make the various controllers as independent of each 
other as possible to break down the current monolithic state of Cocoon 
core that makes it such a pain to develop in.

Now for these new developments we should IMO not depend on the 
unnecessary complication that our environment abstraction means.

At least I would like to use the servlet apis on the controller level. 
We could introduce the own environment abstarction first inside the 
sitemap controller.

> 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.

Look, Cocoons current messiness depends on a large amount of small 
things. If we not are able to improve these areas one at a time Cocoon 
will stay as messy as it is.

So now we have the situation that we all agree about that there is need 
for a radical improvement of Cocoon in general. But it seem rather hard 
get any decisions about changing anything in particular.

Maybe Cocoon of today is what we deserve ;)

> 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.

Ok. Any link to the discussion?


View raw message