cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] The Real Component Simplification
Date Thu, 05 Jan 2006 14:19:02 GMT
Vadim Gritsenko wrote:

> Berin Loritsch wrote:
>> Daniel Fagerstrom wrote:
>>> "Decomponentization" could start right away. Do you have any 
>>> concrete examples of components that shouldn't be components?
>> Pipeline (sure we have two implementations, but that doesn't mean it 
>> has to be a component)
> Five implementations. And I imagine after interface cleanup and for 
> pipeline API, pipeline should stay component.

Not necessarily.  Just because there are multiple implementations 
doesn't necessarily mean it is a component--or should be a component.  
There are some useful things we can do with a Pipeline such as using the 
Decorator pattern as opposed to inheritance to add features.  Or we 
could use other OO tricks that just aren't possible or too difficult in 
a component environment.

> URL interpretation
> ?

SourceResolver and company

>> Just about anything that is not a Processor, Generator, Transformer, 
>> Serializer, or Reader.
> You forgot Matchers, Selectors, and Actions. Every but small projects 
> have bunch of those.

No, I left them out on purpose.  Those are elements of the 
Sitemap--which is an implementation of the Processor.

> Stores. Swapped very frequently, several implementations, and Cocoon's 
> default is not the fastest gun in the west.

Ok.  That works.

> Input/output modules. Tons of them.

:/  I think that there are some better ways of dealing with this...  But 
it is an extension point that is useful.

> It is very simplistic view of the world to declare that only P/G/T 
> deserve to be components. I'd even go as far as claim that P/G/T are 
> implemented by cocoon users the *least* often compared to other 
> interfaces.

Well, as da Vinci said, "Simplicity is the ultimate sophistication".  
The key point of the decomponentization process is to reduce the number 
of extension points to the absolute practical minimum.

By being brave about what we leave out, it forces us to think 
differently about other aspects of the system.  I'm thinking way forward 

View raw message