cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re:
Date Wed, 24 May 2000 18:59:43 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 will check it in soon (as long as nobody is against this)

>   I restructured the code a little to add some functionality.
>   The generator now:
>    - includes the modification time/date of each file/directory

It can be used as an example to implement other information (someone
mentioned MIME types). I've realized that the 'modified' attribute is
implemented twice! 

>    - optionally traverses multiple levels of directories

What is it good for?

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

It is part of the SAX ContentHandler interface. A description can be
found in the xerxes code (

>   I removed the file/directory name from the data of each node,
>   since it already appears as an attribute. 

I've realized it and modified the corresponding stylesheet, which
renders it to html. I will commit it soon.

>   I also removed the
>   trailing "/" that was being added to directory names, as I felt
>   it was redundant. 

The trailing '/' was only used to make the <a> tag work in the
stylesheet without any further adjustment.

>   OTOH, I probably should have included more
>   path information in each node, to make it easier to process
>   nested directories.

I still don't see the reason for nested directories.

>   The original DirectoryGenerator used the Java2 method
>   File.getCanonicalFile, so I assumed cocoon2 requires Java2
>   or better

have you removed it?

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

Maybe the separate generate method with no parameters leaves room to use
it outside the request/response context (it's my personal presumtion).

>   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 interface definition is made according to the design pattern in use.
The abstract class fills some commonly used method with code and/or
implements other interfaces as well (you know multiple inheritance from
abstract classes is not possible in java).


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

View raw message