cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [RT] The Real Component Simplification
Date Thu, 05 Jan 2006 15:00:31 GMT
Berin Loritsch wrote:
> Vadim Gritsenko wrote:
> 
>> Berin Loritsch wrote:
>>
>>> 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.

May be


>> URL interpretation
>>
>> ?
> 
> SourceResolver and company

It proved to be very valuable extension point


>>> 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.

Unified object model and expression language could replace many of those.


>> 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 
> here.

Just don't throw out baby in the heat of fight for simplification :)

Vadim

Mime
View raw message