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
