Architectural options


#1

Having read the user guide, an optimal architecture for a situation is not yet obvious. A simple analogy is this: one “window” represents “nation”, with nodes as “states”. An arbitrary number of additional “windows” will represent “state”, with nodes as “cities” (the meaning of node links for purposes of this example is not relevant). A “state window” is created when a “state node” is created on the “nation window”, and clicked on, at which time the new “state window” appears in a new tab frame (SDI). Each “window” is independently zoomable. The UI state persists to a single file. What is the optimal way to model this situation in terms of Go document(s), views, and layers?


#2

I would think that the easiest course of action would be to have a GoDocument per “nation” and a GoDocument per “state”.
You could set up a GoDocument.Changed event handler to notice when a “state” is added or removed from a “nation” document. This would update your tabs. Presumably you could also select the “state” node when the user switches tabs.
Persistence can be accomplished by combining the document state from both the “nation” document and all of its “state” documents, with different attributes for “nation”, “state”, “city”, and the two kinds of links. If you are using XML, you can easily create nested elements, perhaps with the root being a “nation”.