Re: TopicMapProviderFactory configuration properties (was Re: [Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory)

[Kal A. <ka...@te...>]

On Thu, 2003-11-13 at 17:13, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi.
> 
> On Thursday 13 November 2003 09:59, Kal Ahmed wrote:
> 
> | > That's all. Instantiating the subclass directly is not discouraged per
> | > se; you only give up backend independence when doing so. If you don't
> | > need backend independence, no-one forces you to make use of it. :-)
> |
> | That is more or less how I have documented this in the updated
> | Developer's Guide.
> 
> I saw that, thanks a lot for updating that section!
> 
> | > You got me thinking about factory properties, however. I'm beginning to
> | > think that being able to set configuration properties on the factory
> | > object is not a bad idea at all. So we could add property-modifying
> | > methods to the factory base class. That way all concrete subclasses would
> | > inherit a means of setting and accessing configuration properties for the
> | > factory, which would then presumably affect all TopicMapProviders
> | > subsequently created by that factory. How's that sound?
> |
> | Do you mean default properties that get passed to the
> | newTopicMapProvider() method ? If so then I agree - just like selecting
> | which backend to use, specifying the properties for the provider is a
> | common operation for most applications, so having a standard way of
> | reading that configuration information from the environment makes sense
> | to me.
> 
> I believe that the TopicMapProvider "inheriting" configuration properties from 
> the factory is an option, but not always necessary or appropriate. I do not 
> believe that the set of *factory* configuration properties should be passed 
> directly to the newTopicMapProvider() method by the default implementation as 
> provided by the abstract base class.
> 
> I would think that it should be up to the concrete implementing subclass to 
> decide just what to do with these properties, and that the abstract base 
> class should only define the means for storing and retrieving them. The only 
> thing that needs to be guaranteed by all concrete subclasses of 
> TopicMapProviderFactory, IMHO, is that any change to any of the configuration 
> properties only affects *subsequently* constructed TopicMapProviders, rather 
> than retroactively modifying properties of TopicMapProviders created prior to 
> the configuration property change.
> 

I think that the best way of making this clear in the API is to leave it
as it currently is with an initialise() method that receives the
configuration properties. I don't really like the idea of the
TopicMapProvider pulling properties from the TopicMapProviderFactory. If
I under stand you correctly, I think you feel the same way. My proposal
was just that you have TopicMapProviderFactory.newInstance() read a
default set of provider configuration properties. Then when you call the
newTopicMapProvider() method, those properties get passed through by the
factory to the initialise() method of the Provider. If you call the
newTopicMapProvider(Properties) method, then the properties passed
through to the Provider are the default properties overwritten with the
properteis passed into the newTopicMapProvider(Properties) method. 

Cheers,

Kal