cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Stimmel <>
Date Tue, 23 May 2000 21:28:31 GMT
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

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

  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

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

View raw message