cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: DirectoryGenerator using abstract Source
Date Thu, 14 Jul 2005 09:36:55 GMT
Gianugo Rabellino wrote:

>On 7/14/05, Joerg Heinicke <> wrote:
>>Michael Wechner <michael.wechner <at>> 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"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?


View raw message