cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Knodt <>
Subject Re: XPathDirectoryGenerator
Date Tue, 27 May 2003 21:06:29 GMT
Hash: SHA1

On Tuesday 27 May 2003 22:29, Conal Tuohy wrote:
CT> Torsten Knodt wrote:
CT> TK> Hello,
CT> TK> I'm currently working on my patchset of the week ;). One part
CT> TK> is a modularized
CT> TK> DirectoryGenerator. The only what is currently not included is the
CT> TK> XPathDirectoryGenerator. As it can simply be simulated by
CT> TK> XInclude, why
CT> TK> having the code doubled? Or have I understood something wrong
CT> TK> with this thing?
CT> Is it an issue that XPathDirectoryGenerator mixes concerns by traversing
CT> a file system and also parsing and extracting XML from files?
I think it's a mis-design. I would understand, when XPathGenerator would allow 
to filter on this, but including is (IMHO) wrong there. I think a generator 
should generate source (first make XML out of it) and not do any magic on it.

CT> This seems like a reasonable convenience to me, similar to the MP3/Image
CT> etc DirectoryGenerators.
I must agree, that is not really a difference to the MP3/Image 
DirectoryGenerators. It won't be a problem to extend to modularisation to 
allow to add DOM parts to the output. I think I will simply add this, convert 
XPathDirectoryGenerator to it, put it in Bugzilla, and all can look at it ask 
think about it. Thanks for your thoughts.

CT> Also, is XPathDirectoryGenerator cachable?
Code looks like DirectoryGenerators are cacheable. The documentations says no. 
I'm not yet an expert there in.

CT> Because XIncludeTransformer currently isn't.
When I'm not wrong, this part is already in work. Else, it's on my Todo list, 
which gets longer *sigh*. Someone should implement clone() or fork() on 

- -- 
Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
Version: GnuPG v1.2.2 (GNU/Linux)


View raw message