cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: [proposal] Cleaning up our component library
Date Wed, 28 Jan 2004 06:52:11 GMT
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit 
:

> 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.

> ...I propose to deprecate those components in 2.1 and to remove them 
> in 2.2...

In cases where this just needs sitemap changes, no problem. But if 
deprecation requires code changes to existing applications we might 
want to move in smaller steps.

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?

-Bertrand


Mime
View raw message