[Tm4j-developers] Re: Re: TopicMapFactory refactoring

[<Ren...@da...>]

ReHi Kal,

In general it sounds good and I am really looking forward to these chan=
ges to=20
see how your API will work together with our research project.

In the end it is your decision when to do the refactoring considering t=
hese=20
conceptional aspects. But due to my experiences it is advisable to do t=
hem as=20
early as possible. The more code you have and the more backends are imp=
lemented=20
the bigger and more complex are the changes you will have to do. If I w=
here you=20
I would even go further. I would fix the memory backend first until it =
would=20
seem perfect to me. Afterward I would adapt the results to the other ba=
ckends.=20
If you consider the resource time, I think you would need less of it th=
is way.=20
But you are the manager of this project and that is why you make the de=
cisions.

By the way - I have another point which can be improved, I think ;-)

When creating a BaseName for Example you use the method createBaseName(=
String=20
id). This method will use the Constructor public BaseName(TopicMap tm, =
String=20
id) or something like that. All in all you can only create a BaseName w=
ith an=20
id. If there is the wish to add a BaseNameString you have to add it wit=
h the=20
add method of BaseName. I think the user is not interrested in the id m=
ostly=20
when creating a BaseName. What is interressting for him is the BaseName=
String.=20
Sometimes he does not want to concern about the id at all. That is why =
you=20
should give him the opportunity to let the API generate the id. There c=
ould be=20
two methods.

createBaseName(parent) if the user is not interessted in the id
and
createBaseName(String id, parent) if the user wants to choose an id him=
self
and=20
createBaseNameString(String baseNameString, parent);

or later:=20
Topic.createBaseName()
and=20
Topic.createBaseName(String id)
and
BaseName.createBaseNameString(String baseNameString)

The same is also true of other child elements of  a Topic Map which usa=
bility=20
could be improved. But this can wait until the TM API interfaces are=20
implemented, because you will have to change this afterwards again. Wha=
t I=20
consider to be the most important thing now, is to adapt TM API interfa=
ces to=20
TM4J.

Greetings to all...



Ren=E9 Freude (Ren...@da...)=20

DaimlerChrysler AG=20
Research - Information & Communication=20
Software Technologies / Methods & Tools=20
(RIC/SM)=20

Berlin / Germany    =20



                                               =20



	ka...@te...
	16.12.02 17:50
	Bitte antworten an kal
=09
=09
		=20
		 An: Rene Freude/FT/DCAG/DCX@wK-EMEA2
		 Kopie: tm4...@li...
		 Thema: Re: TopicMapFactory refactoring

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 th=
anks
> to Kal Ahmed for starting to fix some issues of the TopicMapFactory t=
hat
> 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. Neverthe=
less I
>  think that this changes can not be the final solution. If I had unde=
rstood
> Kal Ahmed right, he is also thinking this way. He mentioned two or th=
ree
> alternatives he is considering to be suitable. Over the weekend I als=
o
> 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 fact=
ory
> methods to create its direct childs and/or add methods for references=
 like
> the subject indicator. The benefit would not only consist of an extre=
me
> increase of usability but also of the fact that some unnecessary mist=
akes
> 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=
 when=20
attempting to combine two objects from different topic maps (e.g. when =
trying=20
to call a.setType(b) where a is a Topic from TopicMap1 and B is a Topic=
 from=20
TopicMap2).

> Consequently the number of Exception are thrown while the creating pr=
ocess
> of a TopicMap could be reduced to a tolerable level ;).
> But I also see that you have much more to do than refactoring your Co=
de.
>

Yes there would be. I think that in the interests of making an 0.8.0 re=
lease=20
soon so that people can start to play with the two new back-ends and gi=
ve=20
some feedback/bug reports on those, I will probably not implement this =
for=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



=