cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: [proposal] Cleaning up our component library
Date Wed, 28 Jan 2004 07:47:38 GMT

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


Mime
View raw message