cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: SAXConnector use cases (was Re: [VOTE]: The future of the SAXConnector)
Date Sat, 29 Jun 2002 12:31:42 GMT
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 ?

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 

>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).

There's an interesting feature in Avalon role management that is IMO not 
enough used : hints, which associate short names to full class names. 
Their use is currently limited to ComponentSelectors, but they could 
also be used in other configurations to avoid naming classes for builtin 

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 
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)

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.

>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.

>It would be enough to have a cocoon configuration trigger that says:
> - assemble pipelines for maximum performance (means no debug/trace
> - assemble pipelines for maximum information (means lots of debug/trace

And this is where hints come in handy. Imagine such a configuration :

<pipeline type="caching">
    <connection type="profiling"/>

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".

>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.

Thoughts ?


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

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

View raw message