Data Operations 2.0.0

Changes and improvements

note

The new version is still able to read models from version 1.x.x. This means migration should be straight-forward for most cases. For a step-by-step upgrade follow the migration guide.

Model schema adjustments

DataOperations were originally designed as an abstract type to support extending the schema. After implementing many different types already, we have seen this was never really needed. Abstract types impose some restrictions in our tooling which led to the decision to implement types as a field instead. This gives us three clear advantages:

• It is easy to switch between different types throughout our tooling.
• It is easier to migrate from DataCommands to a Custom operation first, before switching to a more appropriate type later.
• It is much easier to define new types in an expansionResource, without the need for your own Metamodel.

Before

<dataOperation type="operations::CreateOperation">
  <name>register</name>
  <parameterGroups>
    ...
  </parameterGroups>
</dataOperation>

After

<dataOperation>
  <type>Create</type>
  <name>register</name>
  <parameterGroups>
    ...
  </parameterGroups>
</dataOperation>

Simplified parameter types

Previously we had ValueFieldParameter to refer to valueFields and AssociationParameter to refer to linkFields. This would sometimes be confusing from the perspective of the model. To simplify this a bit the new situation is as follows:

• FieldParameter with a field reference for both value and linkFields.
• AssociationParameter with a dataElement reference for references without corresponding field. (New)
• Deprecated ValueFieldParameter.
• Deprecated field reference on AssociationParameter.

Angular Expanders upgrade

In version angular-expanders 7.0.0 the ui model has enabled abstract compositions for both the DataView and DataConnector. Previously data-operation connectors, forms and actions were modeled as extensions. These have also been changed to implement these abstract types instead.

As a result they will show up differently in the model files. Instead of a separate file for each connector or view, they will now be inlined in the file of their parent.

Before

<!-- featureModules/country/model/dataViews/City.xml -->
<dataView xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/6/0/0">
  <name>City</name>
  <dataConnector>country::City</dataConnector>
</dataView>
<!-- featureModules/country/model/dataViews/City/DataOperationForms/Add.xml -->
<dataOperationForm xmlns="https://schemas.normalizedsystems.org/xsd/operationsAngular/2">
  <name>Add</name>
  <connector>country::City::register</connector>
</dataOperationForm>
<!-- featureModules/country/model/dataViews/City/DataOperationActions/Add.xml -->
<dataOperationAction xmlns="https://schemas.normalizedsystems.org/xsd/operationsAngular/2">
  <name>Add</name>
  <connector>country::City::register</connector>
  <dialog>form-page</dialog>
  <form>country::City::Add</form>
  <roles>
    <role>add-action-button</role>
  </roles>
</dataOperationAction>

After

<!-- featureModules/country/model/dataViews/City.xml -->
<dataView
    xmlns="https://schemas.normalizedsystems.org/xsd/angularProjects/7/0/0"
    xmlns:oa="https://schemas.normalizedsystems.org/xsd/operationsAngular/3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>City</name>
  <dataConnector>country::City</dataConnector>
  <views>
    <view type="operationsAngular::DataOperationForm" xsi:type="oa:dataOperationForm">
      <oa:name>Add</oa:name>
      <oa:connector>country::City::register</oa:connector>
    </view>
    <view type="operationsAngular::DataOperationAction" xsi:type="oa:dataOperationAction">
      <oa:name>Add</oa:name>
      <oa:connector>country::City::register</oa:connector>
      <oa:dialog>form-page</oa:dialog>
      <oa:form>country::City::Add</oa:form>
      <oa:roles>
        <oa:role>add-action-button</oa:role>
      </oa:roles>
    </view>
  </views>
</dataView>

Migration guide

Since the model files have changed, it is advised to do migration when you don't have many open PR changes to minimize merge conflicts.

The first step is to add the new version of the bundle to your expansionSettings:

expansionSettings.xml

<expansionResources>
  <expansionResource>net.democritus.bundles:data-operations-bundle::2.0.2</expansionResource>
</expansionResources>

Note: Also make sure your expanders-maven-plugin and/or micro-radiant are up-to-date to avoid any version issues.

Migrating Data Operations

The migration happens when loading the model. This means you will be able to expand your application just fine. To persist the changes your best option is to run the following transmutation:

Transmutation

UpgradeDataOperationsApplication

• Upgrades all DataOperations to their corresponding types. E.g. converts a operations::CreateOperation to a operations::DataOperation with the Create type.
• Replaces all ValueFieldParameter and AssociationParameter (with field) with FieldParameter.

Migrating Data Operations Angular

The migration of angular views is mostly just a rewrite of the model as well. The transmuter below will also clean up the previously used extensions:

Transmutation

UpgradeDataOperationsViewModelAngularApp

Upgrades all DataOperation connector and views from an extension to a composition child. When successful, the transmutation will also delete any files previously storing the extensions.

Some inputs have been removed from the form components. If you used the form components with an <element>Model as input, you will now first have to convert the model to a dataOperation model using the <DataOperation>ModelMapper service! Most usages of the form component should be in expanded code however which won't need any changes.

Upgrading MR plugin

To load and edit the new model files with MicroRadiant, you will need to get the latest plugin for data-operations.

That should be all, happy coding!