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.
Stefano:
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?
Stephen.
If you want to submit patches to improve the situations, they will be welcome.
-- Stefano.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
