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 > org.springframework.web.context.support.XmlWebApplicationContext which > has one of the more bloated APIs that I have had the misfortune to see > http://www.springframework.org/docs/api/org/springframework/web/context/support/XmlWebApplicationContext.html. > > 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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
