cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [proposal] Cleaning up our component library
Date Wed, 28 Jan 2004 10:52:22 GMT
On 28.01.2004 07:52, Bertrand Delacretaz wrote:

>> One problem often mentioned is that Cocoon provides to many 
>> possibilities to achieve some goals. Cocoon's flexibility ends where 
>> it is more confusing than helpful. Therefore I want to propose to 
>> remove/deprecate the components that are no longer the correct way to 
>> go, that are misleading by name or just don't do what their type of 
>> component is intended to do....
> 
> 
> Sounds good, too many options do not help.
> 
>> ...Another example or the "wrong" components as 
>> [Read|Write]DOMSessionTransformer or SourceWritingTransformer. They 
>> are not transformers in the closer sense, they just tee the pipeline. 
>> They should be completely removed and replaced with either 
>> XModuleSource and aggregation (read) or FlowScript's processPipelineTo 
>> (write)....
> 
> 
> Ok on the intention, but by removing these you force users to change 
> their code, not only replace some components in the sitemap as you 
> mention. I'm not sure about removing them unless they get in the way.

You are right. I did not have the "more than sitemap"-changes in mind 
when thinking about the consequences.

> How about:
> a) components marked "deprecated" log a warning when used (or when used 
> for the first time)
> b) maybe add an option to throw an exception when such components are 
> used ("strict deprecation")
> c) deprecated components requiring code changes to user applications are 
> kept in 2.2, unless keeping them is too much work.
> 
> WDYT?

With our deprecated block we have another mean to lead the user to the 
new components. When it's excluded the application will just not work. 
But I don't know if this is true for 2.2 and real blocks too.

So alltogether:

a) Components that are just renamed or replaced with only sitemap 
changes (FileGenerator => XMLGenerator, DirectoryGenerator => 
TraversableGenerator (or however it is called ;-) ), StreamGenerator => 
XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2.
b) Components that need "real" application changes as processPipelineTo 
or anything similar are also deprecated in 2.1, but will be kept in 2.2.
c) Deprecation messages:
Strict deprecation for a) components. 80% are catched by "file" => "xml" 
and "file" is the default generator and "xml" will be it.
Loose deprecation with a warning on every usage (otherwise they are to 
easily lost in the logs) for b) components. If we also use strict 
deprecation here, we don't really need b).

Joerg

Mime
View raw message