cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Date Sun, 30 Jun 2002 16:58:19 GMT
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
> >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.
> >
> >
> Yes. I also think there are many components that actually aren't. If we
> consider some of the subpackages of org.apache.cocoon.components such as
> browser, deli, hsqldb, we can say they aren't component (a
> component-like interface and a single implementation).
> So why have they been designed as components ? Because we want to be
> able to choose to include them or not, and if yes, give them some
> configuration. The usual way for this is to define a component and
> configure it in cocoon.xconf, leading to over-componentization. But what
> other way do we have ?

What other way? What about the good old "new Object()"?

> The case or connectors is somewhat different as there are several
> independent implementations have been identified : profiling,
> well-formedness, debug. There is also the Cocoon pipeline probe at
> which is a transfomer, but could also be
> connector.
> >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.
> >
> >
> Having a component to implement a feature doesn't mean that each and
> every user will be able to write its own new implementation, or has to
> know how this component operates. Cocoon comes with a lot of builtin
> features, and the average user chooses which of them to include or not
> using cocoon.xconf (and also the <map:components> of the sitemap).

Yes, but that's becoming too implicit. There is no real difference
between what is required and what can be left out if everything uses the
same mechanism.

> There's an interesting feature in Avalon role management that is IMO not
> enough used : hints, which associate short names to full class names.

Oh, no, I disagree. 'hints' are re-inverting the control and many on
avalon-dev suggest that cocoon should not have been using Avalon for
those cases where it already needed what classes to instantiate.

If avalon is used just as a simpler way to perform classname lookup,
that's not exactly a difficult thing to do ourselves.

> Their use is currently limited to ComponentSelectors, but they could
> also be used in other configurations to avoid naming classes for builtin
> implementations.

No, let's stay away from hints as much as possible.
> Look to the following xconf lines with the eyes of a cocoon newbie. The
> first one is what we currently have with the fully qualified class name,
> and the second one makes use of a hint for that class.
> 1 : <pipeline
> class="org.apache.cocoon.components.pipeline.CachingPipeline"/>
> 2 : <pipeline type="caching"/>
> What the average user wants is to choose between caching and
> non-caching, i.e. the _feature_ and doesn't care about the actual class
> name (which btw, makes cocoon.xconf unreadable and frightening)

Agreed, totally. But the above is not something that avalon should be
used for because avalon is not a framework for instatiating objects. As
I said, you have java to do that.
> The second line would be easily possible if we added hints in
> cocoon.roles for the implementations of each role built into cocoon.
> This would allow a classname-less cocoon.xconf for standard uses, while
> still allowing advanced users to plug in their own implementations by
> explicitely naming the class.

Hmmm, I dunno, what do others think?

> >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.
> >
> >
> Yes. And as the current SAX connector is not fully suitable for this,
> that's why I'm finally in favor of their removal.

Ok, cool. So I think we have agreement now.
> >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)
> >
> >
> And this is where hints come in handy. Imagine such a configuration :
> <pipeline type="caching">
>     <connection type="profiling"/>
> </pipeline>
> We just name the wanted fonctionnality, and not the classes that
> implement it. No "org.apache.cocoon.components.pipeline.CachingPipeline"
> or "org.apache.cocoon.components.saxconnector.ProfilingSAXConnector".
> Just "caching" and "profiling".

Yes, something like this... but I'm skeptical about placing the more
weakly typed indirection for class lookup. We should have more explicit
configurations at the expense of a weaker extensibility but a higher
> >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?
> >
> >
> My impression is that FS is smelling stronger when so many classes have
> to be explicitely named by a user that just wants to process XML. A
> broader use of hints would inject simplicity in the xconf without
> sacrificing the flexibility that we need. Cocoon.xconf would then change
> from a class-assembly description to what it really should be, a
> readable and manageable configuration file.
> Note also that hints could equally be used in the <map:components> of
> the sitemap. I already proposed this in
> but
> it didn't had much acceptance at that time because the treeprocessor was
> just born and this was incompatible with the compiled engine.

I agree that classnames are verbose, but hints might become as verbose,
or, if not, might lead to name collisions once we have blocks. So I'm
not a big fan of hints at all.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message