Skip to main content

2 posts tagged with "data-operations"

View All Tags

Data Operations 2.0.0

· 4 min read
Jorren Hendriks
Jorren Hendriks
R&D Engineer

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>

Data Operations 1.1.0

· 2 min read
Jorren Hendriks
Jorren Hendriks
R&D Engineer

We've moved data-operations out of its experimental phase. This means it can now be adopted by any project which may need it. They are a successor to data-commands which means you can decide to migrate data-commands which undoubtedly have many uses throughout your application.

You can get started by adding the bundle:

<expansionResources>
<expansionResource name="net.democritus:data-operations-bundle" version="1.1.0"/>
</expansionResources>

Please note data-commands will not be deprecated and can remain to be used. Data-operations provide a more expressive model and improvements to the runtime so we do recommend switching, but this is not a requirement. If you want to migrate, the decision tree below will help you with deciding which type of Operation is the best replacement for a data-command.

Command Decision Tree