RE: [TM4J-users] Using topic map as model

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

Hi Norbert,

> at the moment I try to do a little topic map editing tool.
> I asked myself what would be the best way to handle the
> topic map data for a gui.
>
> My first thought was to use the topic map directly as a
> model for the components. But there arise several problems:
>
> - except the ScopedObject I need a own model for every topic map object
> - a gui editing panel should have a submit/cancel action. while every
>    factory method which creats topic map objects (e.g. createTopic())
>    is inserting the Objects immediately into the topic map it's really
>    hard to cancel creation of a new topic map object.
> - textfields don't have explicit models. So it's hard to display topic
>    map objects. (ok, this could be done using my own textfield)
>
> The alternative I'm trying at the moment is to read data from topic
> map objects into Collections which the gui is using/modifying.
> But thats a way the application faces itself with tons of nested
> loops in order to get the data out of a topic map object and afterwards
> back in again.
>
> Any suggestions?
>

The approach I took with TMNav's editing capabilities was to do a copy of
the topic map object being edited and pass that to the editing dialog - the
copied object would be created by a separate, memory-based TopicMapFactory,
so creating and modifying the copy does not in any way modify the topic map
which is being edited until the user chooses to commit their changes - at
that point, another copy is performed to overwrite the propoerties of the
topic map object being edited with the properties of the temporary object.

The major weakness with this approach is that it is possible to modify a
topic in such a way that when the updates are applied, the topic actually
merges with one or more other topics and so the change can appear to have
caused the topic to "get lost". However, I think that this could be
addressed either:
a) by smart GUI design that displays the merge occurring (somehow)
b) by checking the changes made before they are committed to see if a merge
would occur.

Currently, there is no real API support for (2) but I think it would be
useful if the API provided some way of indicating the set of topics that a
topic would be merged with *if* it were added to a particular topic map.

Hope this helps!

Kal