cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Dependency on WebApplicationContext
Date Sat, 25 Feb 2006 19:24:04 GMT
Daniel Fagerstrom wrote:
> I'm trying to get the blocks fw working again after the switch to 
> Spring. It doesn't seem to be particularly easy as the tree processor 
> now is sprinkled with concrete references to 
> CocoonXmlWebApplicationContext which in turn extends the 
> which 
> has one of the more bloated APIs that I have had the misfortune to see 
> I thought that we had the goal to make Cocoon layered and make e.g. the 
> sitemap processor usable outside Cocoon. And that the point with Spring 
> was to make Cocoon independent of the container. With the concrete 
> references to the above monster of a class we make Cocoon (if possible) 
> even more monolithic.
Hmm, not sure if we really have these goals. I guess some of us have
while others not. I think, again the open question of a common vision.
What's the real use of making the sitemap processor usable outside
Cocoon? If someone needs something like that it would be much easier to
grep the code and start a new project. Imho, Cocoon can't be made
independent of the container and I see no real benefit of trying to do
this. Imho, you loose more than you win from that.
But as I always said, the current Spring based implementation is a first
version which can be seen as a proof of concept. So we can make
everything even better from this point on.

> I'm completely against having the treeprocessor hardwired to that freak 
> class. The treeprocessor should depend on a (small) interface that 
> describe what it actually need from its container.
Yeah, sure. The tree processor has a long history and as we changed the
underlying container now twice the code got not better from that :( I'm
+1 for cleaning up the tree processor. But imho it's a little bit
difficut to make it independent from the container as we have a
hierarchy of sitemaps, creating a hierarchy of containers. So the tree
processor needs a way to setup a container a get the parent container
for that. Or maybe the code could be moved out of the tree processor to
separate this.
But on the other hand, the tree processor is working. So, is there a
real problem (apart from being ugly) with it? If you want to use the
tree processor, just look it up from the component manager and use it.
It's transparent to users how it does things inside.

> Right now it feels like there are hours an hours of work before I get 
> back to have a working block implementation again.
I'm sorry for that. Of course this was not my intention. Where exactly
are your problems? For me at least everything compiles.

> Carsten, the next time you feel like doing a major refactoring of 
> something that affects other developers, I would really appreciate if 
> you discussed the design for a while, so that the rest of us can give 
> some input.
As I outlined above, I had no design to discuss; I had a prototype which
I commited days ago and then tried to clean up in the last days. The
trickiest part in fact was the tree processor; But we now have a
starting point: we know what we want and we know how we want it; so
everything what is left is cleaning up.

> It would also be better if you made sure that major pieces actually work 
> before throwing away the old working code, and destroy the work for 
> others (me).
Again, what is not working? As you and others have said in recent
threads, the core is working again; there was a problem with the default
handling of sitemap components which should be fixed now. I guess there
are more of these minor issues which we can fix easily as soon as they
turn up. I'm sorry that my work made your work harder, but I wasn't
aware of any such thing; the only piece of code I'm sure I broke is the
ecm block implementation which I simply do not understand to get it
fixed but I'm here to help getting that work again.

But on the other hand I did you a favour and now the Context object
extends the ServletContext :)

Carsten Ziegeler - Open Source Group, S&N AG

View raw message