Short class names in .xconf (was :Re: SAXConnector use cases (was...))

[Sylvain Wallez <sy...@anyware-tech.com>]

Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>  
>
>>Stefano Mazzocchi wrote:
>>
>>>Sylvain Wallez wrote:
>>>
<snip/>

>>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()"?
>  
>

Sure, I (still) now this way ;)

But I was saying that Avalon itself encourages overcomponentization 
since it makes it so easy to manage an object's lifecycle. On a 
"regular" object, you have to manage yourself creation, configuration 
(by passing a child configuration of an enclosed component ?), etc. 
Since we're all lazy, we just ask Avalon to do that, even if not really 
required.

<snip/>

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

I don't have the time to follow avalon-dev (although I must find it 
since important things are happening), but I can guess that this 
re-inversion of control is when a component uses hints to lookup other 
components.

What I suggest here doesn't relate to this problem, as it is to use 
hints as "class short names" in the configuration files. This doesn't 
re-invert anything since these short names aren't used in component 
lookup, but only as a user-friendly way of writing the container 
configuration.

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

What do you mean ? Have the CocoonComponentManager handle these short 
names ? This can be of general interest, so why not add this to Avalon ?

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

Pipelines *are* components. What I propose here doesn't change*anything* 
to Cocoon/Avalon's internals and is just a simplified notation that will 
avoid users to manipulate these clumsy class names, and use short 
feature-related names instead.

No re-inversion of control, no over-componentization. Just simple and 
readable names.

You must also be aware that many Cocoon users consider it for its XML 
processing abilities and aren't really interested in the underlying java 
classes. This is a consequence of being a nice high-level framework. 
Compared to that, the .xconf is really low-level with all these class 
names around and really user unfriendly.

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

Yes, please share your opinions.

I personnaly think this may increase Cocoon's usability and reduce the 
learning curve required for people to start modifying the .xconf.

<snip/>

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

This doesn't reduce extensibility. As I said, we can provide short names 
for components built into Cocoon, but the full class name notation is 
still available for custom implementations.

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

Collisions aren't likely to happen as the scope of a hint (or short 
name) is the role, and I don't really see what will be the problem with 
blocks.

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org