cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject over-componentization scenario
Date Wed, 01 Oct 2003 11:36:04 GMT

Stefano Mazzocchi wrote:

> On Wednesday, Oct 1, 2003, at 09:49 Europe/Rome, Michael Lipp wrote:
>> Hi,
>> having studied the avalon concepts some time ago, I just came upon a 
>> point where I wanted to take advantage of them and failed. Let me 
>> tell you why.
>> I have a problem with filenames of Java files generated from XSPs 
>> becoming too long. So I tracked processing down and found that if I 
>> modified ProgramGeneratorImpl.getNormalizedName a bit, I could fix 
>> this. In old times, I would have had to patch ProgramGeneratorImpl 
>> and put in in the classpath before cocoon.jar or replace it in 
>> cocoon.jar.
>> But we have Avalon. And ProgramGeneratorImpl is a component. So I 
>> thought instead of that nasty patching, I simply write a new 
>> component and change the configuration. GetNormalizedName is private, 
>> so I could not derive and override in the new class, but of course, 
>> this is perfectly legal, and I basically copied the code in my new 
>> class.
>> But when I tried to compile my new class, I found that it needs 
>> access to GeneratorSelector.addGenerator (from the same package) and 
>> that this method is protected! :-(
>> And GeneratorSelector is itself a component, so you cannot say that 
>> it is an intimate helper of ProgramGeneratorImpl. What now? Of 
>> course, I could have copied GeneratorSelector in my new package as 
>> well, but where  may this end...
>> So I went (half) back to the old times: I have a new class, but I had 
>> to put this class in package 
>> org.apache.cocoon.components.language.generator kind of "spoiling" 
>> the original distribution after all.
>> I admit, I have no great experience with Avalon. But to me it seems 
>> that the moral of this is that anything designed as an Avalon 
>> component should not use package visible methods of other classes 
>> unless those classes are only very private helpers. Otherwise you do 
>> not really get configurable components.
> You are completely right.
> Cocoon suffers from what I call "overcomponentization", or "use of 
> avalon where a regular class would have made more sense". I think you 
> found one spot and I also agree with your result at the end. 


As a matter of principal - I have to make a comment here. 

There are assertion onf the Cocoon web site that imply some evil 
associated with "over componentization".  I would like to take you up on 
this.  Now - to give fair warning - I have specific ideas about what is 
and what is not a component.  And I'm thinking in my mind that 
over-componentization of good components is a null-event .. it does not 
exist. However, I am trying to rationalize this with you assertions .  
Can you help me out here?  I can confirm that I am an avid non-component 
developer - when appropriate - however - in my mind there is a 
definative point where something is a component as distict from an 
implementation object.  That difinative point concerns publication and 
containment (in my view of the world).

What I would like to know is what (in you view of the world) constitues 
an over-componentization scenario?


> If you want to submit patches to improve the situations, they will be 
> welcome.
> -- 
> Stefano.


Stephen J. McConnell

View raw message