Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F0DB679.30806@verizon.net>
Date: Thu, 10 Jul 2003 14:54:49 -0400
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: cvs commit:
 cocoon-2.1/src/scratchpad/src/org/apache/cocoon/generation
 TraversableGenerator.java
References: <20030710163336.54819.qmail@icarus.apache.org>
 <3F0D96B8.2040407@leverageweb.com> <3F0D9B10.1020605@apache.org>
 <3F0D9FCF.9090105@anyware-tech.com> <3F0DA6D9.1090603@verizon.net>
 <3F0DB3A6.105@leverageweb.com>
In-Reply-To: <3F0DB3A6.105@leverageweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Geoff Howard wrote:

> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>> ...
>>
>>> IMO, the name should reflect the notion of Source and either 
>>> traversal or hierarchy. So what about SourceHierarchyGenerator 
>>> (that's the name of my implementation) or SourceTraversalGenerator ?
>>
>>
>> I would prefer something really simple; like 
>> SourceDirectoryGenerator. Or DirectoryGenerator... Too bad it's 
>> already taken. Can ALL of those implementations (including XPath and 
>> RegExp/Wildcard (for wildcard existing matcher code should be 
>> reused)) be merged into one code base, of the DirectoryGenerator 
>> (does it make sense?)?
>
>
> That's kind of what I was envisioning originally - if the code is
> merged (and it seems good to do so) 80% of the users will use it
> for file system directories, and naming it anything too different from
> "DirectoryGenerator" will obfuscate it's function.  But some of the
> proposed TraversableSources don't fit with "Directory" at all (at least
> XMLDB doesn't), so I thought "hierarchy" type names a good compromise. 


CollectionGenerator -- somebody already suggested this name, right?


> Wild proposal: merge all code into one class, named something very
> clear (like TraversableSourceHierarchyGenerator) and subclass that
> with DirectoryGenerator (or something very like it) and have that
> subclass override nothing:
>
> public class DirectoryGenerator extends 
> TraversableSourceHierarchyGenerator {
>
> /**
>  * Identical to superclass - class only for name/function clarity.
>  **/
>
> }
>
> too crazy?


No :)
That is usual practice to support backward compatibility.

Vadim