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.
