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
