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

[Florian G. H. <f.g...@gm...>]

=2D----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 wou=
ld
| > inherit a means of setting and accessing configuration properties for t=
he
| > 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 f=
rom=20
the factory is an option, but not always necessary or appropriate. I do not=
=20
believe that the set of *factory* configuration properties should be passed=
=20
directly to the newTopicMapProvider() method by the default implementation =
as=20
provided by the abstract base class.

I would think that it should be up to the concrete implementing subclass to=
=20
decide just what to do with these properties, and that the abstract base=20
class should only define the means for storing and retrieving them. The onl=
y=20
thing that needs to be guaranteed by all concrete subclasses of=20
TopicMapProviderFactory, IMHO, is that any change to any of the configurati=
on=20
properties only affects *subsequently* constructed TopicMapProviders, rathe=
r=20
than retroactively modifying properties of TopicMapProviders created prior =
to=20
the configuration property change.

Cheers,
=46lorian

=2D --=20
=46lorian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/s7vSgW2VC0bQC+MRAtPfAKDVSxQmF/GDRhAPEXLSkXchzzIrUgCfTFib
38DibksRXYLpsXujmZ6wsNU=3D
=3DyGtn
=2D----END PGP SIGNATURE-----