[Tm4j-developers] Re: Re: Design question about the TopicMapFactory

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

On Thursday 12 December 2002 15:31, Ren...@da... wrote=
:
> Hello again,
>
> I just saw that there is no protection against adding the same Topic to=
 two
> different TopicMaps anyway:
>
> this.vosTopicMap =3D tmProvider.createTopicMap(vosTopicMapLocator);
> this.superClasses =3D tmProvider.createTopicMap(superClassesLocator);
> superClasses.addTopic(vosTopicMap.getFactory().createTopic("foobar"));
>

That was true in 0.7.x - although TopicMap.addTopic() has been deprecated=
 for=20
quite a while now. In 0.8.0, that method is finally removed (I left some =
time=20
before removing it to allow people a chance to update their code).

> Ok - you might say if such things happen it is the fault of of the
> developer using your API. But I am really a little bit confused. If I w=
ant
> to create a Topic I use the specific TopicMapFactory and it is added
> automatically to its parent. But if I want to create a BaseName for my
> Topic I have to add it myself. And all the time I have to be very caref=
ul
> of not using the wrong TopicMapFactory because i could make my whole mo=
del
> inconsistent:

Yes, my next proposed big set of changes to the API would be to make the=20
construction/containment model more closely aligned to TMAPI, that means =
that=20
at the least I would make all TopicMapFactory methods require that the pa=
rent=20
of the created object be specified (so createBaseName(String) becomes=20
createBaseName(Topic, String)) or to go all the way along the TMAPI path =
and=20
remove the Factory class entirely and replace it with createXXX() methods=
 on=20
the parent object (so TopicMapFactory.createBaseName() becomes=20
Topic.createBaseName())

>
> superClassesTopic.addBaseName(vosTopicMap.getFactory().createBaseName(.=
=2E.))
>;
>
> I prefer two solution:
>
> 1.)=09From a TopicMapProvider I can get a TopicMapObjectBuilder / Facto=
ry
> which belongs to a specific backend implementation. With the
> TopicMapObjectBuilder I can create any TopicMapObjects.
>
> =09a.)=09These TopicMapObjects could be added to their parent
> automatically by giving the wanted parent in a parameter:
>
> =09=09TopicMapObjectBuilder builder =3D
> myProvider.getTopicMapObjectBuilder();
> =09=09// When creating TopicMap I dont have to say where it should be
> added when dealing with a TopicMapObjectBuilder tied to a single
> TopicMapProvider
> =09=09TopicMap myTopicMap =3D builder.createTopicMap(locator);
> =09=09Topic myTopic =3D builder.createTopic(id1, myTopicMap);
> =09=09builder.createTopic(id2, myTopicMap);
> =09=09builder.createBasename("bla", myTopic);
> =09=09.... and so on
>
> =09b.)=09Or manually by the attaching idea I described in my last
> email. If a TopicMap Object is created I tell it to attach itself to a
> TopicMapObject which acts as a container.
> =09=09If it is already child of a parent and only it deregisters
> there and registers at a new parent. And a TopicMapObject can be the ch=
ild
> of only one parent with this strategy.
>
> =09=09TopicMapObjectFactory factory =3D
> myProvider.getTopicMapObjectFactory();
> =09=09// When creating TopicMap I dont have to say where it should be
> attach itself when dealing with a TopicMapObjectFactory tied to a singl=
e
> TopicMapProvider
> =09=09TopicMap myTopicMap =3D factory.createTopicMap(locator);
> =09=09Topic myTopic =3D factory.createTopic(id1);
> =09=09mytopic.attach(myTopicMap);
> =09=09factory.createTopic(id2).attach(myTopicMap)
> =09=09factory.createBasename("bla").attach(myTopic);
> =09=09myTopic.detach();
> =09=09.... and so on
>

These are good suggestions. 1b is very much like the original TM4J API - =
which=20
I eventually found got too confusing. 1a is a good idea though.

>
> 2.)=09There could be a factory tied to a single TopicMap which is calle=
d
> TopicMapBuilder. But if it is tied to a specific TopicMap it should add
> TopicMapObjects to it while creating them. Not only
> =09Topics and Associations but also all other elements. This would make
> the whole creating process more consistent.
>
> =09TopicMapProvider provider =3D .....
> =09TopicMap myTopicMap =3D provider.createTopicMap(...);
> =09TopicMapBuilder builder =3D myTopicMap.getFactory();
> =09// When creating with Topic I dont have to say where it should be ad=
ded
> when dealing with a TopicMapElementFactory tied to a single TopicMap
> =09Topic myTopic =3D builder.createTopic(id1);
> =09builder.createTopic(id2);
> =09// But I have to do when creating a BaseName
> =09builder.createBaseName("bla", myTopic);
>
> =09A manually attaching version is senseless here I think.

I agree.

>
> All in all I would say that solution 1b is the most flexible one while =
1a
> or 2a are more comfortable.
> Finally I want to say that I do not declare my ideas to be the right on=
es.
> Maybe I have forgotten to include some aspects into my considerations.?
>

The only other model I have seen is the TMAPI model where the "factory"=20
methods are found on the parent objects (e.g. Topic.createOccurrence()).

My preference at the moment is to implement 2b properly. Probably making =
those=20
changes for 0.9.0 so that the new Factory methods are implemented in 0.9.=
0=20
and the old methods are deprecated in that version - then the old methods=
 can=20
be removed before 0.10.0 (or 1.0 even...lets think positively!)

How does that sound ?

Cheers,

Kal=20

PS - I'm kind of ruling out doing this for 0.8.0 as I am almost ready to =
go=20
with an 0.8.0a1 release. But if people prefer to get this nailed down now=
,=20
I'm happy to hold off until the implementation is done.=20

--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: ka...@te...
p: +44 7968 529531
w: www.techquila.com