[Tm4j-developers] Re: TopicMapFactory refactoring

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

Hi Rene,

On Monday 16 December 2002 13:12, Ren...@da... wrote:
> Hello,
>
> I am that impertinent to write to the developers mailinglist, because I
> think this topic is placed best here. At first I want to epress my than=
ks
> to Kal Ahmed for starting to fix some issues of the TopicMapFactory tha=
t
> fast. That's why I can wait a little bit with my implementations and do=
 not
> have to refactor code myself ;)
>

:-) Thats a good thing!

> I am convinced with the new changes the whole process of creating a
> TopicMap will be more consistent, comfortable and intuitive. Neverthele=
ss I
>  think that this changes can not be the final solution. If I had unders=
tood
> Kal Ahmed right, he is also thinking this way. He mentioned two or thre=
e
> alternatives he is considering to be suitable. Over the weekend I also
> thought a little bit about this topic and came to a conclusion:
>
> I think the best variant is already realized in the TM API interfaces.
> Every single TopicMapObject (except from leaves) has one or more factor=
y
> methods to create its direct childs and/or add methods for references l=
ike
> the subject indicator. The benefit would not only consist of an extreme
> increase of usability but also of the fact that some unnecessary mistak=
es
> on part of the user of the TM4J API could be entirely abolished:
>
> - Using a wrong factory when creating a TopicMapObject
> - Adding a Topic that does not fit to a special TopicMap
> ...
>

Yep, I think that you are right in this analysis. I think that also the=20
existing implementations should be made more robust to throw exceptions w=
hen=20
attempting to combine two objects from different topic maps (e.g. when tr=
ying=20
to call a.setType(b) where a is a Topic from TopicMap1 and B is a Topic f=
rom=20
TopicMap2).

> Consequently the number of Exception are thrown while the creating proc=
ess
> of a TopicMap could be reduced to a tolerable level ;).
> But I also see that you have much more to do than refactoring your Code=
=2E
>

Yes there would be. I think that in the interests of making an 0.8.0 rele=
ase=20
soon so that people can start to play with the two new back-ends and give=
=20
some feedback/bug reports on those, I will probably not implement this fo=
r=20
0.8.0, but will make it a task for 0.9.0.

How does that sound ?

Cheers,

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

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