cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [RT] The Real Component Simplification
Date Wed, 04 Jan 2006 18:48:45 GMT
Daniel Fagerstrom wrote:

> Berin Loritsch skrev:
> ...
>
>> Much like Photoshop with filter plugins.  The block idea would be 
>> more analagous to complex macros for Photoshop.  They may provide new 
>> plugins to use in the package, but they allow you to do predefined 
>> things.
>
>
> I don't know enough about Photoshop to be able to follow your analogy. 
> Are you talking about extension points and plugins as in Eclipse or 
> are you talking about some other level of granularity?

Pretty much.

> ...
>
>> The real component simplification is to get rid of the components 
>> that will never be swapped out.  It's unnecessary for them to be 
>> components anyway.  That makes the task of providing an Avalon bridge 
>> for existing components much easier.  And it achieves the goal that 
>> the internals are not a scary mess any more.
>
>
> "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)
URL interpretation
Just about anything that is not a Processor, Generator, Transformer, 
Serializer, or Reader.

As to Processors, I see the following implementations:
1. current sitemap--complete with its matchers, selectors, actions, and 
tree processor
2. rails-like router

The others are planned extension points that several people have written 
solutions for.



Mime
View raw message