From: Joerg Heinicke > 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.
I'm +1 to move the named components into the "deprecated" block because this perfectly signals your intentions and removing in 2.2 is okay for me because I think there will follow some more 2.1.x releases before we ship 2.2. -- Reinhard
