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]
