I don't think a removeModuleProvider method would be warranted. Or, maybe I'm just near-sighted. I don't see a reason to re-use a RegistryBuilder, really.
-----Original Message----- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Friday, September 10, 2004 4:09 AM To: HiveMind Dev List Subject: Re: [HiveMind] implementing module dependencies James, I am sure things are far from perfect. But before getting completely overwhelmed by other ways to solve this I had to dump my current understanding of it out of my brain by committing a working solution ;-) I think it should at least be a step in the direction which we all seem to agree on. But please take a look and see if you find better ways to solve this. I also thought about a RegistryBuilder#addModuleProvider(ModuleProvider). But doesn't that beg for a removeModuleProvider(ModuleProvider) or at least a getModuleProviders()? Another solution is of course to add a constructRegistry(List, Locale) processing a List of ModuleProviders. Btw I support renaming ModuleProvider to ModuleDescriptorProvider. Regardless of what the final solution looks like I think trying to keep things simple for client code should be the paramount goal. --knut On Fri, 10 Sep 2004 01:00:43 -0400, James Carman <[EMAIL PROTECTED]> wrote: > What if we added a method to RegistryBuilder like this... > > class RegistryBuilder > { > public void addModuleProvider( ModuleProvider provider ); > public void constructRegistry( Locale locale ); > public static void constructDefaultRegistry(); > } > > This would avoid having to come up with an AggregateModuleProvider class > (although one could be provided too). I would also recommend changing the > name of ModuleProvider to ModuleDescriptorProvider, since that's what it > really provides and there IS actually a Module class. > > As for the YAGNI of this parser/provider framework, I don't know how I feel > about that one. I don't know if it'll ever be NEEDED, but it isn't too > tough to implement (you'll love how I cram my naming convention suggestion > down your throats here too)... > > public class BaseModuleDescriptorProvider implements > ModuleDescriptorProvider > { > private List moduleDescriptors = new LinkedList(); > > public void addModuleDescriptor( ModuleDescriptor moduleDescriptor ) > { > moduleDescriptors.add( moduleDescriptor ); > } > > public final List getModuleDescriptors() > { > return moduleDescriptors; > } > } > > public class ClasspathModuleDescriptorProvider extends > BaseModuleDescriptorProvider > { > private final ModuleDescriptorParser parser; > > public ClasspathModuleDescriptorProvider() > { > this( new XmlModuleDescriptorParser() ); > } > > public ClasspathModuleDescriptorProvider( ModuleDescriptorParser parser ) > { > this.parser = parser; > } > > public void addDescriptor( String resourceName ) > { > addModuleDescriptor( parser.parse( > Thread.currentThread().getContextClassLoader().getResourceAsStream( > resourceName ) ) ); > } > } > > public interface ModuleDescriptorParser > { > ModuleDescriptor parse( InputStream in ); > } > > This code is off the top of my head here, so please forgive any compiler > errors (my brain compiler doesn't work well after midnight). I would doubt > that you would use the same provider to parse different file types. A > single provider would most likely be parsing all XML files (or SDL, may it > rest in peace). You could even extract a superclass here... > > public class ParserBasedModuleDescriptorProvider extends > BaseModuleDescriptorProvider > { > private final ModuleDescriptorParser parser; > > public ParserBasedModuleDescriptorProvider(ModuleDescriptorParser parser) > { > this.parser = parser; > } > > protected void addModuleDescriptor( InputStream in ) > { > addModuleDescriptor( parser.parse( in ) ); > } > } > > Sorry for the code-heavy message! > > > > > -----Original Message----- > From: Knut Wannheden [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 07, 2004 6:39 PM > To: [email protected] > Subject: Re: [HiveMind] implementing module dependencies > > On Tue, 07 Sep 2004 13:38:51 +0200, Achim Huegen <[EMAIL PROTECTED]> > wrote: > > Maybe a case, where composition is better than inheritance. > > Although SDL is resting in peace, the support of both XML and SDL would > > result in : > > XmlModuleProvider, SdlModuleProvider, ClasspathXmlModuleProvider and > > ClasspathSdlModuleProvider. > > > > I would suggest a common ancestor that deals with resources and > > which expects a parser for resource processing. the parser parameter > > is optional and the XML Parser is used as default: > > > > I see what you're saying. But isn't this maybe a case of YAGNI? I > didn't quite understand all the details of your idea either. > > After trying out a few solutions this is what I've come up with > (boring bits left out): > > class RegistryBuilder { > Registry constructRegistry(ModuleProvider provider, Locale locale) {...} > static Registry constructDefaultRegistry() {...} > } > > interface ModuleProvider { > List getModuleDescriptors(ErrorHandler handler, RegistryAssembly > assembly) {...} > } > > class ClasspathXmlModuleProvider implements ModuleProvider { > ClasspathXmlModuleProvider(ClassResolver resolver) {...} > } > > class XmlModuleProvider implements ModuleProvider { > XmlModuleProvider(ClassResolver resolver, Resource resource) {...} > XmlModuleProvider(ClassResolver resolver, List resources) {...} > } > > class AggregateModuleProvider implements ModuleProvider { > AggregateModuleProvider(List providers) {...} > } > > Note that the constructRegistry() method only accepts a single > ModuleProvider (not a List). The idea is that using multiple > ModuleProviders should be a quite rare case, where the > AggregateModuleProvider can be used instead. If it just weren't such a > pain to construct a List with a single element in Java... > > I'm thinking if it would make sense to replace the XmlModuleProvider > and ClasspathXmlModuleProvider with a single: > > class XmlModuleProvider implements ModuleProvider { > XmlModuleProvider(ClassResolver resolver) {...} > XmlModuleProvider(ClassResolver resolver, Resource resource) {...} > XmlModuleProvider(ClassResolver resolver, List resources) {...} > } > > Thoughts? > > --knut > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
