cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] Simplifying setup
Date Mon, 01 May 2006 13:59:35 GMT
Please provide a concrete example of what you are proposing before 
checking anything in.  Then we can discuss this.

Daniel Fagerstrom wrote:
> People, I'm fed up with the sickening complicated setup sequence in 
> Cocoon. Much of the complication is related to setting up the 
> component manager and general over componentization.
> I'd like to remove the component container setup from the concern area 
> of Cocoon. The component container should instead be setup by the 
> servlet container using a ServletContextListener and made available to 
> the Cocoon main servlet through a servlet context attribute (the 
> details will be slightly different in the blocks context).
> Furthermore the setup contains a number of classes and components with 
> fairly overlapping and fuzzy concern areas: The CocoonServlet creates 
> a CoreUtil which creates a CocoonBeanFactory which in turn is used to 
> get the Cocoon component, which in turn delegates most of it job to 
> the SitemapLanguage which also is a component that is managed by the 
> CocoonBeanFactory. A fun exercise for the interested is to try to 
> figure out how and where the Cocoon component is configured and created.
> Now, I don't see any reason at all for Cocoon and SitemapLanguage to 
> be managed components, it just complicates everything. And for the 
> Cocoon component there is not much use anymore. Its responsibilities 
> are rather vague. I suggest that we just move whatever useful thing it 
> might do, to the main servlet and use Servlet instead of Processor as 
> top level interface (as discussed before, so many sitemap internal 
> details has been added to Processor that it is not useful as an 
> abstraction anymore anyway).
> For the Cocoon main servlet I suggest that we start from the 
> SitemapServlet 

> and modify it so that it gets the bean container from a servlet 
> context attribute instead of being injected. Also the sitemap path 
> (for non default valiues) could be taken from servlet config init 
> parameter instead of the current mechanism.
> The SitemapServlet is rather minimal so some functionality from the 
> Cocoon component and the CocoonServlet could be moved to it. But I 
> think we should strive to keep it minimal. More advanced functionality 
> like multi part mime handling could preferably be moved to servlet 
> filters.
> The suggested architecture will make it much easier to maintain and 
> understand Cocoon, and will also make it simpler to reuse and to add 
> new controllers to (a Flowscript controller or a RoR inspired 
> convention controller e.g.). The CLI and Portlet environment will need 
> some refactoring if we follow the above path. But the CLI need some 
> work anyway and for the Portlet environment I would guess that getting 
> closer to the servlet standards just should simplify things.
> /Daniel

View raw message