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.

I already asked the question for replacement when Daniel introduced the (X)ModuleSource's. The StreamGenerator reads from the stream - but that's not what the component generator is about. The difference between generators should not be the type of the sources, but the type of the content. The same is true for the FileGenerator. For those I propose a simple XMLGenerator as we have a HTMLGenerator. The type of the source is given by the source, i.e. @src. Furthermore the name FileGenerator is misleading as it reads from http: or cocoon: or any other XML source too.

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

Similar as for the FileGenerator the DirectoryGenerator is "out of date", we already have the replacement in our CVS.

I guess there are some more components that does not meet their intention (seen from the component type's POV). I propose to deprecate those components in 2.1 and to remove them in 2.2. When the clear separation of concerns is more obvious than now (generation, aggregation, source, etc.) it will also be easier for the Cocoon users (especially new users) to dive into Cocoon and understand the principles of it. Therefore some backwards "incompatibilities" (it's not real incompatibility, but some components in the sitemap must be replaced when moving from 2.1 to 2.2) are the price to pay.

WDYT?

Joerg

Reply via email to