Sylvain Wallez wrote:
> So finally, I'm in favor of removing SAXConnector _now_, but be prepared
> to see something appear in the future that will be really orthogonal to
> pipelines and will hopefully improve the so-called "user experience"
> when an error occurs !
I see your point and I agree, but I would like to add a little warning
to what you're trying to achieve.
Cocoon suffers from overavalonization, the anti-pattern of usign Avalon
too much, even when a more simple solution would make more sense.
This is the best example: since it's possible to abstract the SAX
connections, then we make them components and allow users to plugin
their own.
Sure it's powerful, but it's *too* powerful. In order to plug them in
and write goo ones, they have to know *all* the cocoon internals very
well. Since not even us were able to create more than a few non-obvious
examples of those components, this is clearly labelling itself as FS.
Rather, you propose a serious and important issue with
'development-oriented pipeline assembly', but this doesn't mean that the
user has to know what SAX connector is used for this.
It would be enough to have a cocoon configuration trigger that says:
- assemble pipelines for maximum performance (means no debug/trace
overhead)
- assemble pipelines for maximum information (means lots of debug/trace
overhead)
So the uses doesn't have to *know* how to do it, but the functionality
you wanted is there without the need for overcomponentization which
smells like FS too much.
How does that sound?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
