-----BEGIN PGP SIGNED MESSAGE-----
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
mankind.
Regards
Torsten
- --
Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+09NZvxZktkzSmiwRAiNMAJ92SS62XZFVioW3ij+q+UPnvmGt5gCfbc50
yz1m9ymIK3eHxdld/R7oG0w=
=4zGY
-----END PGP SIGNATURE-----
