cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re:
Date Tue, 23 May 2000 23:06:08 GMT
Jonathan Stimmel wrote:
> Ok, so I stuck my neck out a little and put my reputation on the
> line, so I had plenty of incentive for me to follow through
> on my promise to start taking an active role. Last night I
> jumped into "cleaning up", which I've
> attached (a patch would have been larger than the resultant file).

> I believe I've conformed to Sun's coding standards, though it also
> reflects my own coding style:
>   - I dislike single-character variables, except for indexes
>   - I avoid lines longer than ~75 characters
>   - I like short methods (less than 20-30 lines or so)
>   - I like whitespace =)
> Comments welcome (of course)... here are mine:
>   I restructured the code a little to add some functionality.
>   The generator now:
>    - includes the modification time/date of each file/directory
>    - optionally traverses multiple levels of directories

well, it looks like flexibility syndrome to me, but it's ok.
>   I honestly don't understand the role of startPrefixMapping,
>   so I just left it alone (I was tempted to remove it, since I
>   wasn't sure it really made a difference in this case).

I'm not sure...

>   I removed the file/directory name from the data of each node,
>   since it already appears as an attribute. I also removed the
>   trailing "/" that was being added to directory names, as I felt
>   it was redundant. OTOH, I probably should have included more
>   path information in each node, to make it easier to process
>   nested directories.

Can you send us the DTD that results, or, at least, a sample document?
>   I used SimpleDateFormat to format the file modification date,
>   but it cannot be used with all locales (and I'm unsure of the
>   effect in that case).
>   The original DirectoryGenerator used the Java2 method
>   File.getCanonicalFile, so I assumed cocoon2 requires Java2
>   or better

Components are not required to be 1.1 compatible, but use 1.2 methods
only if _absolutely_ necessary.
>   It seems odd that two method calls (setup and generate) will be
>   made to process a given request, forcing the class to store
>   very short-lived data at the class level. My instinct tells
>   me that setup (or something similar) would only be called
>   when instantiating the class (while parsing the config file)
>   and request-specific data would be passed directly to generate.

I know, I had the same feeling but Pier had good reasons for this... but
I forget know what they were.
>   I don't understand the need to both create an interface and an
>   abstract class that implements the interface. I would expect that
>   one or the other should suffice (I would tend towards an abstract
>   class), and trying to use both just increases complexity (and
>   maintenance overheatrying to use both just increases complexity
>   and maintenance overhead. (This is not the only place this is done)

The pattern of using interfaces, then abstract implementations, then
actual implementations is the best one for truly componentized models,
because while Abstract classes are actual classes (with constructors and
all that), interfaces just represent a "view" of their shape.

Moreover, while interfaces can do multiple inheritance, you can't do it
with abstract classes.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message