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 will describe maybe the most important pattern-hierachy in the implementation. The PageElement is a common superpattern of all objects, which can be placed on a page. In the non-framework code, the PageElement participate as follows in the hierachy:
Highligtable → Snapable → PageElement → Inscription, Arc, RegionElement, GuideLine, GuideLineSnapble → Aux, BendPoint, Node → Place, Transition
Here we have the clear correspondens, that Place is subpattern of Node, that again is a subpattern of GuideLineSnapable, which again…
The important thing to notice here is the interface for PageElement; Snapable is where some of the code for snapping is placed, and Highligtable is the code for something, that can be highlighted. These are not that interesting. PageElement has for the most part graphical methods, these are not so interesting for now. A PageElement also has some interesting methods: Each object on a page knows, which page it is on (SetCPNPage, GetCPNPage), whereby their also know in which net their, since a CPNPage has a reference to the net.
A PageElement can also be cloned (the clone method). This means that every object on a page can be cloned. A PageElement also has a method called postprocessing. This method is called right after the net elements has been loaded and it for now called in a specific order (See CPNetUnPack) This methods ensures that objects, which has children (i.e. guidelines), gets a reference to the corresponding children objects.
Besides the interface of PageElement, there are also to event related methods, which is important for this hierachy, namely onChanged and onSemanticChanged. These methods should be called when ever something changes graphically, a normal changed-event, or when the semantic changes, semanticChanged-event. Children are normally responsible for probagating the event to their parents.
A Node has only two subpatterns, Place and Transition. A node has collection of arcs with which it is connected (scanable through scanArcs) A node also has a name which has a special semantic regarding duplicate names on different nodes.
Node also has the code, that makes inscriptions snap to the node.
A Place holds direct references to its 2 permanent children, the InitMark and the PlaceType. A place object is “born” with it's permanent children, and always has these (meaning that these references never point to NONE). This invariant has to be uphold. A place can also have other children; a PortType or a FusionInfo.
Place has different methods for hierachical operations, these should be clear to interpret directly from the code.
A place can also be part of a fusionset and has therefore a reference to the FusionSet
A Transition holds, like a Place, a reference to it's 3 permanent children; TransGuard, TransTime and TransAction. These should be threated like inscriptions of Place.
Both Place and Transition has a method called localCheck, which determines if the status (color) of the node should checked or unchecked (orange).
A Transition also holds a reference to it's static subpage if any. (it can only have one subpage, but there can different instances of this transition with references to different instances of the subpage)
An Inscription is a PageElement, although it is not a child of a CPNPage. This has historic reasons. An inscription has many different self explanatory methods, but a thing to notice is, that an inscription can exists although it is not shown. This is achieved by letting the inscription be the defaultInscription (which is different for the different types of inscriptions). If one looks at PlaceSetPlaceType the idea about this and the permanent children will hopefully be clear.
There are two subpatterns of Inscription; PlaceInscription and TransitionInscription. These have references to their corresponding parent and maintains some stuff.