Gianugo Rabellino wrote:
On 7/14/05, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
Michael Wechner <michael.wechner <at> wyona.com> writes:
Wow, 2 years ago! And what about starting a real migration now by
starting with the unclean way (DirectoryG extends TraversableG with
old namespace and directory/file metaphore as you wrote it),
deprecating it at the same time and making the TraversableG the
officially supported one?
just one note re such a migration. Wouldn't it make sense to actually
"rename" the TraversableGenerator to CollectionGenerator and introduce
something like
ResourceGenerator (or does that exist already?) and do
DirectoryGenerator extends CollectionGenerator
FileGenerator extends ResourceGenerator
such that the terminology is consistent?
For the FileGenerator I have another name in mind since a long time:
XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
else generator too. From where the XML is read is independent on the generator
itself, but only depends on the source provided via @src in sitemap. Having this
in mind ResourceGenerator is not the best name possible IMO and will continue
the irritating naming.
Don't want to rain on the party, but this has been exactly the kind of
discussion that led nowhere a couple years ago. I'm now convinced that
File/DirectoryGenerator are there to stay, there is just too much
stuff depending on it. Apart from naming issues (beware the bikeshed
effect), my take would be:
1. move TraversableGenerator to src/core, deprecate DirectoryGenerator
leaving it untouched
2. insert some log.xxx("DG is now deprecated, please use TG instead"),
where "xxx" is promoted from debug to error in a few release cycles
3. optionally start introducing XMLGenerator the same way (though the
only path I can foresee is via c&p)
I don't think it is a good idea to deprecate things that have been
arround in Cocoon from the very beginning and is part of about every
book, tutorial and article that have been written about Cocoon.
If they where considered harmfull in some way, hard to maintain or was
in the way for developing new important stuff I would agree in
deprecating them. But I don't see that it is the case.
A much better way to handle old stuff where we have found better ways of
achieving what they are intended for is IMO doing like we did for XSP,
remove it from core and move it to a block.
For the DirectoryGenerator we could have a certain DirectoryGenerator
block, or put it together with some other "obsololete" stuff that belong
together in some way in a block. Or we could have an
"backcompability2.1" block, with everything that we find old fashoned
and want to move away from core.
In any case, avoid "extends" like the plague. If anything, the hassle
we're going to have because of that bunch of generators extending DG
should prove how extends can be harmful.
I don't follow you here, care to expand on it?
Actually, it might be worth
thinking about refactoring the whole stuff using composition.
So, what parts are you considering for the composition?
/Daniel
