Jbpm-side Process Designer Schema description

First, the main structure of the code

The so-called process designer, no wonder read XML file, graphic display, manipulate graphic elements, change XML file, write back, that's all.

In this case, the process structure of the designer is very clear: first, the XML framework parsing XML file for the model model component, and then the model model component is presented as a component view component; The user operates on the component view component, These operations are synchronized to the Model module component; When the last user saves the Model module component is parsed back into the XML file by the XML framework, which is uploaded to the server or overwrites the original XML file locally.

Then the code structure is clear: The XML framework, model module components, and component view components. But wait, model and component how to interact? There is a need for a GEF framework to graft the links between the two. At the same time, a process designer often has to edit multiple process definitions at the same time, compared to the specific process definition, the designer has some global objects, including the System menu bar, the tool bar, the entire designer layout framework (Processdesigner), Designer Portals (Processeditor), and Themodel objects that are responsible for saving global properties and publishing/subscribing to custom events.

Second, component View components

Very directly, the component view component refers to the view elements that are involved with the user in relation to the process definition. Note the attribute here: it is related to the process definition, that is, not including the System menu, tool bar, and so on. These view elements are simple, including drawing boards, various node elements, and connector elements.

The code is located under Org.jbpmside.view.component and Org.jbpmside.view.component.node. Main classes Surfacecomponent, Nodecomponent and Connectioncomponent. Looking at the class name is very clear what components these classes represent:

Surfacecomponent represents a drawing board;

Nodecomponent represent nodes;

Connectioncomponent represents the connecting line;

The class under Org.jbpmside.view.component.node is a subclass of the Nodecomponent class, representing a specific single node type, including the start node, the end node, the fork node, the join node, and so on.

The component view component uses DEGRAFA to render representations.

There is currently a missing attribute popup component that functions to show and modify node/connector properties.

Model Module

XML process definition file resolves to local model model component, local modeling is consistent with jBPM4 PVM modeling, code is under Org.jbpmside.model, important class:

processmodel represents process definition;

Nodemodel represents the node definition;

Connectionmodel represents the connection line definition;

The rest is the model class of the specific node type, such as Startnode/endnode/tasknode.

The current model class is also very simple, because the previous period is focused on the Component View Component section, and will soon be fully synchronized with the JPDL specification, and Processmodel/nodemodel/connectionmodel will be refactored. The goal is exactly the same as the JBPM4 model.

The newest model is located under Org.jbpmside.model.common, the support of Jpdl4 is located under Org.jbpmside.model.jpdl4, the future needs to transfer component and model's association to common package.