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
- Re: [proposal] Cleaning up our component library Joerg Heinicke
- Re: [proposal] Cleaning up our component library Bertrand Delacretaz
- Re: [proposal] Cleaning up our component libr... Andreas Hartmann
- Re: [proposal] Cleaning up our component ... Joerg Heinicke
- Re: [proposal] Cleaning up our component libr... Joerg Heinicke
- RE: [proposal] Cleaning up our component ... Carsten Ziegeler
- Re: [proposal] Cleaning up our compon... Vadim Gritsenko
- Re: [proposal] Cleaning up our c... Geoff Howard
- Re: [proposal] Cleaning up o... Vadim Gritsenko
- Re: [proposal] Cleaning up o... Joerg Heinicke
- RE: [proposal] Cleaning up our compon... Reinhard Poetz