cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject [proposal] Cleaning up our component library
Date Wed, 28 Jan 2004 01:40:03 GMT
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.



View raw message