Thanks for the link Daniel. I took a look at it and reread your original email. Parts of it I think are good ideas but I have one major concern. I think it is a bad idea to architect things such that the CocoonServlet will not run unless some ServletContextListener has previously run. However, I have no problem at all with allowing for ServletContextListeners to override or extend default behaviors though.
I've been working a lot with Jetspeed lately. It uses Spring for darn near everything. However, it doesn't seem to use the approach discussed below. Rather, they just have an assembly directory with a whole bunch of configuration files. It seems you can just add your own file to the directory to add whatever behaviors you want. I guess I prefer that behavior over having to modify the web.xml (actually, I hate modifying the web.xml). As for getting rid of the Cocoon object and your other suggestions, I don't have any real concern there. Actually, I'd prefer a main servlet that gets a Spring configuration and then just hands off control to a component configured there. But that might make it all even harder to understand since it would then be very loosely coupled. Ralph Daniel Fagerstrom said: > Ralph Goers skrev: >> >> >> Daniel Fagerstrom said: >>> Carsten Ziegeler skrev: >>>> Daniel Fagerstrom wrote: >>>>> <snip rt/> >>>> I'm mostly fine with your proposed changes if you think that this >>>> helps >>>> Cocoon. In the end all changes that don't require to rewrite or change >>>> our current blocks are fine for me. >>> It will mean some changes for the portal block as it use the Cocoon >>> component and the same complicated setup as the the CocoonServlet. >>> Geting a component container that is setup by a servlet context >>> listener >>> through the portlet context should work fine a simplify the portlet >>> setup as well. >> >> Please provide an example of what this would look like. I really need >> to >> understand how this will simplify anything. > > Here > http://static.springframework.org/spring/docs/1.2.x/reference/webintegration.html#intro, > > you can see the standard way of integrating a Spring container in a web > framework. I propose that we should do the same in Cocoon. That doesn't > mean a simplification in itself, but the refactoring of the core that I > propose mean that it will be much easier to follow what happen in Cocoon > and thus taking part in development. It will also mean that it will be > easier for people who want to build new things, like a RoR style > controller or a flowscript controller to do that. > > --- o0o --- > > For the rest of your mail Reinhard have already answered that. > > It is time for you to back up all your opinions with some actual coding > on the trunk. > > /Daniel >
