How do I extend existing plugins?

In some scenarios, your metamodel will be an extension on an existing metamodel. In that case, you will need to add support for your target metamodel by creating a plugin that extends the plugin of said existing metamodel. This section details how to integrate these new elements into the editor's tree view and handle their specific behaviors.

There are two scenarios:

1. Your metamodel has an extension reference to a target metamodel, and you want to add elements of your metamodel in the tree of the target metamodel.
2. Your metamodel contains elementClasses that define a superClass from a certain target metamodel. You want these subclasses to be editable in the target plugin.

1. Integrating Model Extensions into the Tree View

In order to allow elements linked to the model by an extension reference to appear as nodes in the main tree structure, the plugin metamodel introduces a ElementTreeExtension.

An ElementTreeExtension:

• attaches the element of an extension to the editor's tree view
• is defined within the <elementTreeExtensions> section of your editorModelExtension
• targets an extensionReference, indicating that this tree extension will draw its elements from that reference of the targeted element.
• targets an elementTreeNode (the NodeType) to clarify the node that this extension targets.

<editorModelExtension xmlns="https://schemas.normalizedsystems.org/xsd/editorElements/3/4/0">
  <name>workflows</name>
  <elementTreeExtensions>
    <elementTreeExtension>
      <name>workflows</name>
      <actions>
        <editorAction>workflows::createWorkflow</editorAction>
      </actions>
      <extensionReference>workflows::Workflow::component</extensionReference>
      <nodeType>workflows::Workflow</nodeType>
    </elementTreeExtension>
  </elementTreeExtensions>
</editorModelExtension>

In this example, the <extensionReference>workflows::Workflow::component</extensionReference> indicates that this extension will draw its elements from the component reference of the workflows::Workflow element.

2. Supporting SubClasses of Abstract Elements

When working with metamodels that utilize abstract elements and their concrete subclasses, you need to configure your plugin to correctly handle the creation, display, and manipulation of these subclasses. This involves defining specific components and actions for each subclass, even when they share a common superclass composition.

To add support for subclasses, follow these steps:

1. Define an ElementDetailComponent for the subclass: This ensures that when an instance of the subclass is selected, the editor knows how to display and allow editing of its unique properties.
2. Add an ElementTreeNode for the subclass: This allows instances of the subclass to be properly represented and navigated within the editor's tree view.
3. Define a CreateAction with the subclass's ElementDetailComponent, but specify the composition reference of the superclass: This is a key step. When creating a new instance of a subclass, it will typically be added to a collection (composition reference) defined by its abstract superclass. By linking the CreateAction to the superclass's reference while specifying the subclass's detail component, you can provide a new option when the user creates a new instance.

Let's illustrate with an example where EnumType is a subclass of an abstract ValueType which is part of a Component:

<editorModelExtension xmlns="https://schemas.normalizedsystems.org/xsd/editorElements/3/8/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>enumTypeElements</name>
  <elementDetailComponents>
    <elementDetailComponent>
      <name>EnumType</name>
      <autogenerate>true</autogenerate>
      <elementClass>enumTypeElements::EnumType</elementClass>
    </elementDetailComponent>
  </elementDetailComponents>
  <actions>
    <editorAction type="editorElements::CreateAction" xsi:type="createAction">
      <name>createEnumType</name>
      <reference>elements::Component::valueTypes</reference>
      <elementDetailComponent>enumTypeElements::EnumType</elementDetailComponent>
    </editorAction>
    <editorAction type="editorElements::DeleteAction" xsi:type="deleteAction">
      <name>deleteEnumType</name>
      <elementClass>enumTypeElements::EnumType</elementClass>
    </editorAction>
  </actions>
  <elementTreeNodes>
    <elementTreeNode>
      <name>EnumType</name>
      <actions>
        <editorAction>enumTypeElements::deleteEnumType</editorAction>
      </actions>
      <elementClass>enumTypeElements::EnumType</elementClass>
    </elementTreeNode>
  </elementTreeNodes>
</editorModelExtension>

By following these steps, you ensure that your plugin correctly integrates new subclass types into the editor's functionality, allowing users to create, view, and modify them seamlessly within the context of the larger metamodel.