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.
URL interpretation
?
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.
Stores. Swapped very frequently, several implementations, and Cocoon's default
is not the fastest gun in the west.
Input/output modules. Tons of them.
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.
Vadim
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.
