A running graph application based on the Tensegrity Graph Framework contains many pooled data structures (Geometries, Styles, Images) as well as a number of default templates (Rules, Layouts). When opening older documents you might therefore encounter versioning conflicts where the document data and the data pooled in the launched application are different.

This can happen, for example, when a user changes the application styles or the rules stored in a document. The conflict will then arise the next time the user opens the document in the application.

Since there now exist two different Style definitions, a decision has to be made regarding which one to use. To handle this conflict as easily and flexibly as possible, a user has several options to choose from that depend on the type of conflict present and the situation it occurred in. In this way the user is able to load old documents using the newer d efinitions or even import the old definitions and use them as new runtime defaults.

The following option enumerations exist when resolving a conflict. Some of them are only available in certain contexts, however. The enumeration names are the internal names and may not coincide exactly with the terms seen in the user interface dialog presented to users at runtime.

The most common conflict situations arise when loading a document that contains definitions that are different than the current application definitions.

A similar situation may occur during the import of element and layout definitions (element definitions contain styles, geometries and rules). The only difference here is that no document is loaded, hence the option APPLY_POOLED simply means that the conflicting elements will not be loaded and the APPLY_LOADED option will not present.

Another conflict situation occurs when adding elements to a document from another source. An example for this is the rule conflict which occurs when a node is dragged from the repository into the document after the node rule it was using has been changed in the document.

Conflict types exists for all the different types of definitions that are part of the application:

Geometries and styles can be further divided into items and descriptors. For this reason, items are marked in the conflict dialogs with a symbol.

“Style Name Conflict” does not mean that there is a conflict between names, but that there might be a difference between the style of a loaded element and the style definition with the same name in the application pool it refers to.

An “Attribute Conflict,” on the other hand, is a real conflict that has been detected by comparing the attributes of the loaded style definition with the attributes of the corresponding definition in the application pool.

Because a document can be persisted without any definitions stored within it, this section describes the process of handling conflicts in such a context. As a general rule, documents stored without definition metadata cannot be compared to pooled application definitions; hence only a potential conflict can be asserted and communicated to the user.

Style elements are a source of potential conflicts which occur when opening a document that does not contain Style definitions. If the document was previously saved in a different application or possibly in another application state, the current application definitions might differ from the styles referenced in the visual elements of the document.

This conflict should give the user the opportunity to decide if the document elements should be retained (APPLY_LOADED) or if the current definitions of the application pools should be applied to the document (APPLY_POOLED).

Because this conflict can only occur when Style definitions are not stored within a document (no definition attributes to compare), there is no automated way of determining a real conflict. Therefore, only a potential conflict is detected and communicated to the user.

Because of their nature, style and style name conflicts never appear at the same time.

Because style definitions depend on geometry definitions, there are situations that restrict certain conflict options from being chosen when the document definitions deviate from the application defaults.

When applying styles to an element, we have to apply the correct geometry first to ensure the correct primitive structure. This is the reason why you cannot discard geometry definitions when applying style definitions.

This is also the case when a style is automatically applied (added) because it was not part of the pool before. Because this style is used and it is not clear yet to which geometries it might be applied later, all geometry definitions have to be loaded to ensure the correct order, name and type of Primitive objects.

Depending on the type of application, you might want to let the user make all these decisions or maybe none of them. To do so, you can set a default option for each of these conflicts and then suppress the dialog by using the application preferences.

For example, if the user is not allowed to alter the styles in the application (hence they are static), it doesn't make sense to automatically check for potential Style Name conflicts when opening a document. In this case the default option should be set to “Use Loaded” and the suppress option should be selected in the application preferences, so the conflict dialog will not show up for this type of conflict.

You can find a list of all Preference-Keys and possible values in the appendix “Preference Tables” of this manual. (See: Conflict Handling)

Another type of “silent” conflict handling happens if there is no conflict or only a part of the definitions have a conflict. As a general rule you can say that all definitions that have no conflict are used at least in the loaded document independent of the option that is applied.

For Example: A user loads a document with style definitions containing two items. Only one of the items has a conflict with the definition in the style pool and so a conflict option dialog is shown. But even if the user selects “discard loaded,” the item without conflict is applied to the document and the style pool to guarantee that the document can be restored as best as possible.