Re: [Tm4j-developers] Re: Re: TopicMapFactory refactoring

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

I started having a go at an initial implementation of the re-organised fa=
ctory=20
methods and it turned out to be a bit easier than I expected - by making =
use=20
of the existing factory methods I was able to implement factory methods o=
n=20
the objects quite easily.

Can you take a look at these updated APIs and see what you think.=20

Note 1: I have only done a regression test so far - I will need to update=
 the=20
test code to test the new factory methods later if we decide that this is=
 a=20
better API.

Note 2: There is scope for more convenience factory methods such as Rene=20
discussed in his emails. If the general opinion is in favour of this new=20
style of API, then I shall add convenienve factory methods as well (e.g.=20
Topic.addOccurrence(String id, Topic type, Locator resource),=20
Topic.addOccurrence(String id, Topic type, Locator resource, Scope scope)=
=20
etc.)

Cheers,

Kal

On Monday 16 December 2002 18:39, Kal Ahmed wrote:
> On Monday 16 December 2002 17:43, Ren...@da... wrote=
:
> > ReHi Kal,
> >
> > In general it sounds good and I am really looking forward to these
> > changes to see how your API will work together with our research proj=
ect.
> >
> > In the end it is your decision when to do the refactoring considering
> > these conceptional aspects. But due to my experiences it is advisable=
 to
> > do them as early as possible. The more code you have and the more
> > backends are implemented the bigger and more complex are the changes =
you
> > will have to do. If I where you I would even go further. I would fix =
the
> > memory backend first until it would seem perfect to me. Afterward I w=
ould
> > adapt the results to the other backends. If you consider the resource
> > time, I think you would need less of it this way. But you are the man=
ager
> > of this project and that is why you make the decisions.
>
> It is a balancing act between developing the features that people have
> requested (such as RDBMS persistance); the features I want (like the
> unified topic map); and spending time on the other work such as API
> improvements; documentation improvements and so on. There is a cost in
> changing the API all the time, but on the flip-side, working with
> persistent storage mechanisms such as Ozone/Hibernate has made me
> reconsider a number of things about the original in-memory-only API, so=
 it
> is sometimes beneficial to be forced to implement against both in-memor=
y
> and persistent back-ends.
>
> > 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 id). This method will use the Constructor publi=
c
> > BaseName(TopicMap tm, String id) or something like that. All in all y=
ou
> > can only create a BaseName with an id. If there is the wish to add a
> > BaseNameString you have to add it with the add method of BaseName. I
> > think the user is not interrested in the id mostly when creating a
> > BaseName. What is interressting for him is the BaseNameString. Someti=
mes
> > he does not want to concern about the id at all. That is why you shou=
ld
> > give him the opportunity to let the API generate the id. There could =
be
> > 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
> > himself and
> > createBaseNameString(String baseNameString, parent);
> >
> > or later:
> > Topic.createBaseName()
> > and
> > Topic.createBaseName(String id)
> > and
> > BaseName.createBaseNameString(String baseNameString)
>
> Those are good suggestions to carry forward to the next re-working of t=
he
> API. Although I think that I would treat the baseNameString as a proper=
ty
> of BaseName, not as a child object. That means that you would have
> BaseName.setBaseNameString() (or as it is currently called
> BaseName.setData()).
>
> > The same is also true of other child elements of  a Topic Map which
> > usability could be improved. But this can wait until the TM API
> > interfaces are implemented, because you will have to change this
> > afterwards again. What I consider to be the most important thing now,=
 is
> > to adapt TM API interfaces to TM4J.
>
> It should probably be done at the same time, though I am still thinking
> that this should be after 0.8.0.
>
> However, I do not see any reason why the time between 0.8.0 and 0.9.0
> should be as long as it has been between 0.7.0 and 0.8.0.
>
> Cheers,
>
> Kal

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

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