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
