cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Stimmel <>
Subject Re:
Date Wed, 24 May 2000 21:26:17 GMT
On Wed, May 24, 2000 at 08:59:43PM +0200, Giacomo Pati wrote:

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

I had thought about adding mime-types, but decided to to that at a later
date (incremental updates, rather than "hoarde and post" =) I was
also concerned about feature bloat (a concern Stefano has already brought

As for including the modification time twice, I don't like it either,
and after more thought I'm inclined to take one out. Including the time
as milliseconds is useful for sorting; my main reason for adding a human
readable time was so that it could easily be displayed using an xsl

> >    - optionally traverses multiple levels of directories
> What is it good for?

Very little that I can think of. It falls into the, "oh, that
would be trivial to add with little to no performance hit" feature

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

I can understand that. Personally, I find it easier to add delimiters
when I need them than to remember to remove them when I don't.

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

Here's a possible application. I have an xsp page (cocoon1) which
scans a total of six directories and presents a digest/summary of
their contents (sorted by timestamp and location):
  dir1/good	dir1/bad
  dir2/good	dir2/bad
  dir3/good	dir3/bad
An "ideal" (to me) structure for doing this in cocoon2 would be to
us DirectoryGenerator to create the file list, then use a filter
to fill in the details of the files (title, first paragraph, etc.).
Allowing DirectoryGenerator to do a recursive list would simplify
the configuration in this case.

Actually, given the model I just outlined, you could argue (and I
am now inclined to agree) that even including the timestamp is
too much, as the filter will need to do further processing of
the file anyway. Or perhaps DirectoryGenerator should provide a
simple (optional) filter and sorting mechanism to make it
easy to trim the listing to relevant files, so that the filter
can focus on less mundane tasks? (Pardon me as I think out loud
a bit... =)

> >   The original DirectoryGenerator used the Java2 method
> >   File.getCanonicalFile, so I assumed cocoon2 requires Java2
> >   or better
> have you removed it?

getCanonicalFile is gone, but I added another java2 method

I will revisit my changes and refine the class further based on
input from the list. Part of my intention was to get a taste of
cocoon internals development, and from that standpoint I would suggest
you *not* check it in just yet (but then again, that's contrary to
the "release early, release often" philosophy...)

I'm getting long-winded (as usual =) and will respond to your other
comments in a new thread.

View raw message