Carsten Ziegeler wrote:
Intersting stuff - thanks Reinhard and Steven for starting this and
sharing it with us.
Finally I had time to have a *brief* look at it and I have some
remarks :)
I think the pipeline api and sitemap api should be separate things. So
the invocation should rather be in the pipeline api as the base of
executing pipelines. We could than split this into two modules.
I'm not sure if actions belong to the pipeline api; i think they are
rather sitemap specific. All they do wrt to the pipeline is to change
the invocation perhaps. So this could also be done before starting the
pipeline and get the action stuff out of the pipeline api.
Yes, actions definitely don't belong to the pipeline API. They are
sitemap control structures, just like matchers and selectors. The main
difference between matcher and action (besides the pattern/src
attribute) is that actions are allowed to have side effects while
matchers should not.
The classes should be put into different packages: we should separate
between the pure api, helper classes and implementations. This makes
it easier to use the stuff in an osgi environment.
Ok, final comment for today, the idea of abstracting the consumer and
the producer seems appealing. It's like the javax.xml stuff (Result,
Source); the javax.xml stuff has the advantage that the implementation
knows which results and sources are possible: there are only a
handfull of subsclasses; adding own results or sources simply is not
supported.
I fear we will have to follow the same path (which might not be bad).
Reminds me of some old thoughts I had about a Cocoon 3. This can be the
role of a collection of adapters that would convert data for components
that can't directly talk to each other. This complexifies the picture a
bit, but would allow for advanced things such as non-XML pipelines,
mixing SAX, DOM and StAX transparently to e.g. perform some
content-aware construction of the pipeline, etc.
Sylvain
--
Sylvain Wallez - http://bluxte.net
