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 http://www.pankaj-k.net/cpp 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). 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 implementations. 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) 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 >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". >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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101111373910829&w=2 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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
