Much of this information is internal documentation. Care has not been made to make links work and make the documentation conprehensible for outsiders.
This page is dedicated to the documentation of the ideas leading to the new data-structure, which will be implemented for the next version of CPN Tools.
This section contains descriptions of the Goal for the design process.
We are planning the design of the diagram structure.
This section contains descriptions of refactoring of the current structure toward the goal documented above, or to implement new features described in New Features.
The situation for the current work on refactoring is depictured in current refactoring.
This section describes how the refactoring toward the new structure should progress. First we plan to split the current structure into the following structures:
After this is done the plan is work toward the following structure:
The picture shows that we eventually want a the whole design to divided into 5 parts. One instrument part similar to the current one. A index model, where it is possible to change objects. A Graphics model displaying the objects. A Instance model, which consist of all information about instances and is properly the only part communicating with the simulator. Finaly there is the object model consisting of the static part of a net.
The shaky lines on the picture indicate that the plan is first to work toward a structure, where all algorithms are work on/through the graphics. This first phase simplifies the transistion. We could after reaching this first phase decide not to go on to the second phase, where we implement a updating structure with observers. In this structure algorithms are divide between the different parts. Meaning that algorithms regarding only the static structure of a net will be implementet to work on the Object Model only.
There is a “hitlist” of commands to factor out of the code to simplify the command structure:
To implement the “resize current marking” feature some refactoring of moveinstruments are neccesary.
The highlight implementation has a big influence on the class hierarchy (see Description of ContentItem Hierarchy).
To untangle this simplifying the highlighting are necessary.
This section is for describing the current structure.
The ContentItem is the root class of everything visible in a Binder. Description of ContentItem Hierarchy
The current representation of page instances are difficult to work with.
The highlighting implementation are difficult to understand.