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]
