18.3. Further considerations

18.3.1. Overview

The above-described process is sufficient for most of the basic tasks. It is however not appropriate for the development of more comprehensive plugins, as it contains a few points that could hinder the development. In particular, the following problems arise:

  1. Cubetto Toolset has to reload plugins after each change in the plugin code.

  2. The typing of Cubetto Toolset is used in many classes, involving a laborious update of the source code in the case of a change in the typing.

Both problems are addressed in the next sections.

18.3.2. Reloading a Java plugin

The issue of updating the plugins with any change in the plugin code results from the way the tool manages plugins. These are initialized once when starting the program and can then be used for further tasks. As the initialization takes place only once, a reinitialization has to be done after every code change. This process can be done by using the option Reload Plugins in the Plugins menu. You can alternatively restart Cubetto Toolset to do the reload.

Reload Plugins

Figure 18.6. Reload Plugins

18.3.3. Kapselung der Cubetto-Typisierung

The second issue with complex plugin is the access to specific model items that usually takes place via the type of the model item. As we are dealing with a dynamic typing, only the name or the specific key of the model item (see below) can be taken into account in the plugin source code. To avoid a circumstantial acces on specific model items through the complex structure of the typing and to provide a program code annotation close to the types of the model a grammar-specific encapsulation of Cubetto-API in separate classes is done and provided in a class library while doing the typing.

The following code examples show an excerpt of the library for the typing of the Example Model of Nodes and Edges.

package nemt;
public class NaE extends com.semture.ecube.api.elements.Model {

    public java.util.Collection getNodes() {
    }
    public nemt.nae.Node addNode(java.lang.String) {
    }
    public java.util.Collection getTypes() {
    }
    public nemt.nae.Type addType(java.lang.String) {
    }
    public java.util.Collection getEdges() {
    }
    public nemt.nae.Edge addEdge(java.lang.String) {
    }
    public java.util.Collection getViews() {
    }
    public nemt.nae.View addView(java.lang.String) {
    }
}

The notation of the accessing methods follows the corresponding notation of the types. As shown in the API class of the model above, methods according to the scheme get[OT]s() and add[OT](String name) are created for each object type while [OT] represents the name of the object type.

The notation of the accessing methods within the object type API classes is similar as shown below. Property types, where the maximum multiplicity is 1 are accessed by get[PropT]() and set[PropT](java.lang.Object). Property types, where the maximum multiplicity is above 1 can be accessed by get[PropT](), add[PropT](java.lang.Object) and remove[PropT](java.lang.Object).[PropT] represents the name of the property type.

package nemt.nae;
public class Edge extends com.semture.ecube.api.elements.Object {

    public java.util.Collection getNodes() {
    }
    public void addNode(java.lang.Object) {
    }
    public boolean removeNode(java.lang.Object) {
    }
    public java.lang.Object getName() {
    }
    public void setName(java.lang.Object) {
    }
    public nemt.NaE getModel() {
    }
}

The grammar-specific encapsulation of Cubetto-API allows an easier access on the modeled objects on the type level and shortens the resulting program code enormously. The following code shows an exemplary access for the named sample.

//Copy the models source code for key as initial point (Edit-Menu)
var model = manager.getE3Object(725055, 1200569724939, 16570625, 32, 1200485162662, 10678617).getAPIObject();

//e.g.: Output of all connected edges
for (var i = model.getEdges().iterator(); i.hasNext(); ) {
    var edge = i.next();
    if (!edge.getNodes().isEmpty()}
        out.println(edge.getName())
    }
}

//Creating objects
model.addEdge("New Edge");

//Creating views/presentations
model.addViewKK;
viewType.addNodes_and_Edges;

//set/remove single values (min = 0/1; max = 1), prob. throws IllegalArgumentExeption on
violating the range of values
node.setName("Node 1");
node.setName(null);

//insert/delete values
node.addEdge(java.lang.Object value);
node.removeEdge(java.lang.Object value);

//Creating graphical connections [po1.connect(po2, "ConnectorPO1", "ConnectorPO2")]
po1.connect(po2, 0815, 4711);

//Moving graphics/figures:
po.setLocation(Point2D);
po.setLocation("name of figure", Point2D);

18.3.4. External use of the API-Library

For an external use of the class library, created in the back while doing the typing, there is the possibility to export it into a .jar-package which can then be included into an external programming environment. This allows you to use the library for developing a plugin for Cubetto Toolset.

Export typing

Figure 18.7. Export typing

WICHTIG:

When doing the Deployment of the plugin it is not allowed to include the API library into the .jar-package of the plugin.