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