Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 70005 invoked by uid 500); 10 Jul 2003 19:55:15 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 69960 invoked from network); 10 Jul 2003 19:55:14 -0000 Received: from smtp3.wanadoo.fr (HELO mwinf0604.wanadoo.fr) (193.252.22.25) by daedalus.apache.org with SMTP; 10 Jul 2003 19:55:14 -0000 Received: from anyware-tech.com (AToulouse-206-1-11-93.w81-51.abo.wanadoo.fr [81.51.170.93]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 5D439280009C for ; Thu, 10 Jul 2003 21:55:15 +0200 (CEST) Message-ID: <3F0DC4A3.6000908@anyware-tech.com> Date: Thu, 10 Jul 2003 21:55:15 +0200 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: fr, en, en-us 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 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. > > 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? Not so crazy, but incompatible with existing project-specific extensions of the class, as I already mentioned in this thread. Interestingly, this brings us back to the discussion about "internally visible" and "publically visible" methods and attributes we had a few days ago. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com