cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [cocoon-2.2] Deprecation
Date Thu, 25 Oct 2007 17:47:56 GMT
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> I remember though that it was acknowledged that some of the stuff 
>> written on the sheet of deprecated things really had no substitutes or 
>> migration path towards 'new stuff'. Which only means that either it 
>> was on the list by mistake or because 'new stuff' is half baked at the 
>> moment.
> I think that you refer to the idea of deprecating sub-sitemaps which 
> isn't an as good idea as it seemed from a quick glance because there is 
> no equivalent to get the same functionality if you have to replace it 
> with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps 
> for deprecation.


> IIRC it wasn't the functionality of <map:mount> that made some people 
> think that we should deprecate sub sitemaps but the <map:components> 
> part of sitemaps which causes a lot of complicated code that we have to 
> maintain. However, deprecating <map:components> shouldn't be a problem 
> because there already exists a migration path of putting your component 
> definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon.

Agreed, <map:components> section can be deprecated if there is a replacement.

However I would like to clarify though where components are declared. At the 
moment options are:

   For root container, <configurator:settings/> includes:

   For sitemap container, <configurator:child-settings> includes:

   To the sitemap container, <avalon:sitemap> adds:

So if I understand correctly, only /map:sitemap/map:components section in the 
sitemap file is to be deprecated, for both avalon and spring components, and 
first three options are going to be supported. Is this correct?

> The second "big thing" for deprecation that we discussed in Rome was  
> the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the 
> servlet:/ protocol doesn't provide all the "features" of the cocoon:/ 
> protocol but that's mostly caused by getting rid of side-effects.

Yep I'd like to hear more about those nasty "features" :)

> Can somebody who knows the code and the functionality of 
> <map:components> and cocoon:/ in more detail than me comment on this?
>                                       - o -
> I think we should discuss these two big topics first and then we can 
> continue with smaller things like the SimpleFormsTransformer, obsolete 
> input modules, etc. I hope that I find some time soon to write a summary 
> that contains a list with all those components.
> P.S. to Vadim: Of course we will give you a chance to comment on this :-)

Thanks :)


View raw message