Skip to main content

Angular Expanders 5.0.0

· 3 min read
Jan Hardy
Jan Hardy
R&D Engineer

Changes and improvements

This major release marks the beginning of data access (control layer) separation in the angular stack. This has been accomplished by expanding DataAccess interfaces and InjectionTokens. This token can be implemented by a separate expansion resource specific to a certain control layer implementation, e.g. rest-expanders, json:API, ...

For the moment two data access implementation resources exist:

  • angular-svcapi-stack (rest-expanders)
  • angular-stdapi-stack (jaxrs struts replacement)

Expanders Assert 1.0.0

· 3 min read
Koen De Cock
Koen De Cock
R&D Engineer
info

Expanders-assert is a library for writing tests in expansion-resource projects. It has several improvements over the classic expanders-test-utils library and uses more modern libraries like JUnit 5 and AssertJ.

Expanders-assert now has its first major release. We were happy with the current API and are ready to mark it as stable. This means that subsequent changes will be kept backwards compatible.

Important Changes since 0.9.1

Since the 0.9.1 there have been a few changes that you can encounter when upgrading to 1.0.0.

  • Transitive dependencies, like AssertJ, JUnit 5 and expanders-core have been set to provided. They will need to be added explicitly where needed.
  • doesNotHaveTag() can now fail if the tag is not present on the Expander or Feature. This is to prevent false positives due to typo's.
  • Test setup now fails if the TestExpansion parameter is typed incorrectly. This helps with prevent copy-paste errors.
  • The class signature of the ValidationAssert class (returned by assertThatValidationRule()) has changed. This used to have a generic type related to the Composite type, but has been changed since it was not relevant.

New features

The latest changes focus on supporting missing support for transmuters.

REST Expanders 4.26.0

· 4 min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

REST Expanders are now capable of generating fully featured interactions with file resources. Several other fixes and improvements were also implemented. This post will cover many of the improvements introduced from version 4.22.0 to 4.26.0. The latter of which we consider to provide a complete and stable implementation of the file support.

Resources

The expansion resource below provide rest-expanders 4.26.0.

ResourceVersion
rest-jaxrs-stack4.30.0

Changes and improvements

File support

Version 4.26.0 of rest-expanders features the finished implementation for file support. This includes the linking of file resources to regular REST resources, endpoints to upload files and endpoints to download files.

Files are always represented as fields of a REST resource. It is possible to add the option svcapi.endpoint.upload to generate an upload endpoint in function of a field and svcapi.endpoint.download to generate a download endpoint.

An upload endpoint will return a header containing a unique identifier for the file that can passed to the resource endpoints to link it to a new or existing resource.

Example

In this resource a file link is represented by the birthCertificate. As there's a download endpoint for the field, the resource also returns a resourceUri with a link to the download endpoint for that specific file resource.

{
"name": "Snickers",
"uuid": "f9020d14-b1ab-4de3-99a2-f0a2e5a8c71d",
"birthCertificate": {
"resourceUri": "http://localhost:8080/restexample/v1/cats/f9020d14-b1ab-4de3-99a2-f0a2e5a8c71d/download/birthCertificate",
"identifier": "d8227d40-4e8b-4b7f-baf4-52bb8a051e26",
"fileName": "snickers-haz-cheeseburger.jpeg"
},
"breed": {
"resourceUri": "http://localhost:8080/restexample/v1/catbreeds/Maine%20Coon",
"name": "Maine Coon"
}
}

Asset support

A new expansion resource rest-assets-expanders was introduced which provides a default implementation for file links when they are represented by linkfields to assets:Asset. This includes an implementation for the upload and download endpoints. The rest-assets-expanders resource is now also part of the rest-jaxrs-stack resource.

Client aborts

To round out support for files, the REST expanders now handle aborts for file uploads and downloads from the client. The API now returns nothing when these events occur rather than an error. A message will be logged on the server.

Strict finders

There was a long-standing issue in the backend implementation for the API where in a few places finders are used that do not use strict equality to match resource identifiers. This has now been resolved by adding support instead for the same finders, but using strict equality operators. A strict not-equal operator was also introduced for this purpose.

Though the old finders using Eq and Ne operators instead of Se and Sne operators are still supported, the strict operators are now considered default and the non-strict ones only as fallback if they are the only available.

CORS support

The support for CORS handling in the CorsFilterProvider class has been improved to now include the Access-Control-Expose-Headers, in order to whitelist headers returned by the server for use in scripts. New anchors exposed-headers are available to add additional headers if needed.

Better ValueType support

While rest-expanders already provided support for ValueTypes, the AddDefaultRestApi transmutation still provisioned the model using the deprecated ValueFieldTypes. This has now been updated to correctly provision the model with ValueTypes instead.

QuerySearch Expanders 3

· One min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

Version 3 of querysearch is in itself not a major functional upgrade, but it is the first version with its model infrastructure depending directly on its ontology model rather than the old elements-based metamodel. This means that it is expanded using the ontology expanders.

Builders

The querysearch-builders module no longer exists. If it is used in an expanders project, remove the dependency. The builders are now part of the querysearch-core module.

Metamodels 2024.3.9

· 5 min read
Koen De Cock
Koen De Cock
R&D Engineer

Resources

This version introduces a new expansion-resource ontology-metamodel-expanders, which is included in the metamodel stack.

ResourceVersion
nsx-metamodel-stack2024.3.9

Changes

Expanders 2024.3.x introduce the ontology-metamodel-expanders. These expanders have been to made to replace the metamodel-expanders. They use the ontology-based metamodel directly instead of first requiring the GenerateMetamodelApplication transmuter.

Different Project Structure

The new expanders generate a simplified project.

  • The different submodules for each component/ontology have been merged. There is now a single {ontology}-model submodule for each ontology
  • The onion-spec classes have been moved to the test-support module.
  • Harvesting ext files works differently. There are no ext/gen directories. Instead, the expanders harvest every file that was not expanded. The project contains a number of .harvestInclude files, which contain glob patterns for which files to harvest.
  • The expanders module has been removed. Instead, expanders should be implemented in a separate project similar to regular expander projects.

Merged with CompositeBuilder Expanders

Before, it was necessary to expand with model-builder-expanders in a separate project to generate helper classes for transmuters. These expanders have now been merged into the ontology-metamodel-expanders so that this is no longer needed.

Profiles

The new expanders make use of profiles to configure cross-cutting concerns. The Standard Metamodel enables every feature, but it is possible to create new profiles if necessary.

<dataResource type="expansionControl::ExpansionProfile">
<profile name="Standard Metamodel">
<tags>
<tag>#meta.maven</tag>
<tag>#meta.xml</tag>
<tag>#meta.transmutation</tag>
</tags>
</profile>
</dataResource>

XML and XSD

The expanders generate XSD files to describe the ElementClass XML files. The default namespace is https://schemas.normalizedsystems.org/xsd/${ontology}/${version}, which can be modified with the meta.xml.namespace option on ontology. If it contains ${version}, this will be replaced with the actual version.

There are also some changes to the XML representation.

  • References are represented as text-content with the full functional key.
  • Exported XML files have one or more xmlns attributes. In case of mixed metamodels, the XML tags can contain prefixes.

The XMLReaders are implemented to be backwards compatible (they can read both old and new formats).

Miscellaneous

  • MappingContext: Now uses Optional instead of Option. There is an option meta.compatibility.mappingContext.option for backwards compatibility.
  • Dropped support for valueFieldTypes. Attributes now only support DataTypes with String, Boolean or Integer.
  • Dropped DataRefConverter. Keys can be parsed with a method on the {element}DataRef class.
  • Dropped CompositeRegistrar. This was not used.
  • Dropped OptionConverter.
  • CompositeScanner now also scans aggregate relations, e.g. Application -> Component.
  • SpecBuilders no longer support embedding parent specs into the child spec.
  • Now uses dataResource notation instead of _data.xml for most DataResources.
  • expansion directory uses expansionMetamodel name
  • Ontologies now have versions, and imported ontologies without versions are interpreted as being expanded with older expanders.

Angular Expanders 4.5.0

· 3 min read
Jan Hardy
Jan Hardy
R&D Engineer

Migration guide

@imports anchor

Some expanders have been migrated to the new import system, see changelog for the list. This means that feature anchor for imports are no longer necessary and hence they have been removed. To add imports in these files you can add uses statements to the feature expander.

Name changes

Some services have changed name to better comply to the guidelines or to better describe the functionality. This reflects in custom imports and need to be checked.

  • dataConnector.service -> DataConnector-data-access.service
  • dataConnector.datasource -> DataConnector-data-source.service
  • dataConnector.filtersource -> DataConnector-filter-source.service
  • dataConnector-infinite.datasource -> DataConnector-infinite-data-source.service
  • .data models have been changed to .document.

Moved service injection location

Instead of injection services in the constructor they are now injected as variables. This is also done using the new import system, which makes it easier to maintain. See changelog for the list of affected files. It also changed some of the injected names used:

  • dataSource -> dataConnectorDataSource
  • filterSource -> dataConnectorFilterSource
  • route -> activatedRoute
  • translate -> translateService

Mapping location change

DataConnector models are not mapped in the DataConnector-data-access.service anymore, but have there dedicated mapping services now. If any customizations were added to these mappings, then the corresponding harvest code needs to be moved to the new mapping services.

Removed shared components

The DropdownComponent and MultiSelectDropdownComponent have been removed and the use has been replaced with the select component from ngx-ns-core.

Default translation file

The default translation file has changed from en.json5 to gen.json5. This one is used by default, but can be replaced with a custom one by using option angular.defaultLanguage on AngularApp. You should change the name of the harvest file to keep custom translations.

Functional key -> id

In this version a refactoring has been done to not rely on functional key of the DataElement as a variable anymore, but use a generic id name. This impacts routes and method arguments.

Routes

In places where you retrieve the id from the route, the name of the variable should be changed.

Before
const id = this.activatedRoute.snapshot
.paramMap.get('externalId');'
After
const id = this.activatedRoute.snapshot
.paramMap.get('id');

Method arguments

The method interface has been altered in places where the id of an element is needed to use id instead of functional key. This has been done to better comply to the id and displayLabel field added to all element models. This can be used with duck typing as well now.

Before
getSingle({ uuid }: { uuid: string }): Observable<DemoElementModel>
After
getSingle({ id }: { id: string }): Observable<DemoElementModel>

QuerySearch Expanders 2.26.0

· 2 min read
Frédéric Hannes
Frédéric Hannes
R&D Engineer

Changes and improvements

QueryValueType

The QueryValueType enumeration is used to indicate the type of an object passed to a query constraint. Usually a developer will not interact with this, as every constraint factory method that takes it as a parameter, also comes with a variant that does not. In the latter case, the type will be inferred from the object that is passed to the constraint. This can only be inferred for known types, which is mostly primitives and java.util.Date.

As a default, when not recognized, the type would automatically be set to String, resulting into a conversion of the object to String in supporting constraints. With this update the type QueryValueType.OBJECT was added which handles the supplied object as a raw value that is passed directly into JPA, as this is sometimes desired.

Since converting to String is typically not intended behavior for objects that are not of that type, the default when a type cannot be determined is now QueryValueType.OBJECT. This is a breaking change, but should have very little impact, as currently, cases where unknown object types are passed to a constraint are likely to be unintended. In cases where this is intended, the migration guide will explain how to resolve this in the new implementation.

ProcessAutomation 1.0.0

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

In the past six months we've seen adoption of the process-automation component. Feedback has been great and people seem to be happy with the changes we made. We felt the current feature set came to a point where it warrants a first stable release. This of course does not mean development will stop here, as there are many features we still plan to add.

Resources

ResourceVersion
process-automation-component 1.0.0

Feature set summary

The list below should give you a good idea of the features we currently support through process-automation:

  • Fully supports the workflow model.
    • Integrates all defined transitions, including branching transitions.
    • Respects configuration on TaskElements, such as transactionType and TaskOutcomes.
    • Supports configuring WorkflowImplementation through defining QueuedProcessors.
  • Multi-node or multi-instance configurations are supported.
    • Internal state-machine to perform leader-election in the presence of multiple nodes.
    • Ensures smooth execution of transitions, with no conflicting state.
    • Improved scalability by providing extensible queue configurations.
  • Event-based execution model, backed by a queue.
    • CRUD triggers: transition an element on create or modify.
    • Transition trigger: immediately queue the next transition after another completes.
    • DataCommand trigger: transition an element when a command is performed.
    • Schedule trigger: Cron-like configuration for time-based transitions.
    • FlowEngine trigger: behaves similar to the classic Flow implementation.
  • Modular design, ships with standard configurations and can be extended easily.
    • Provided queue implementations: ApplicationPersistence (DB) and InMemory.
    • Provided processing implementations: Asynchronous and ExecutorService.
note

There is no full feature-parity with the Workflow component yet, so consider this when planning to migrate. Reaching this point however is a goal of the following release, as the primary omission is support for TimeWindow/TimeWindowGroup.

Migration guide available in full post... (Read more)

Angular Expanders 4.4.0

· One min read
Jan Hardy
Jan Hardy
R&D Engineer

Migration guide

Branding

Using the option angular.hasCustomBranding we can toggle the default nsx branding off and have custom anchors instead.

caution

Some of the anchor names have been changed:

  • index.html: favicon -> branding-favicon
  • _default-theme.scss: colors -> branding-colors
  • _default-theme.scss: typography -> branding-typography
  • _default-theme.scss: density -> branding-density
  • layout.html: sidebar-branding -> branding-sidebar

Customization

Option angular.hasCustomHeaderContent can be used to turn off the default expanded behaviour of the top bar. With the option angular.hasCustomTableRowActions on a DataView you can have custom anchors instead of the default actions in a table.

caution

Some of the anchor names have been changed:

  • layout.html: header-content -> customization-header-content

Ngx-ns-core update

The size of the runtime library was getting to big for the application's initial load. For this reason the library has been split up in smaller sub-entries, which improves load times and tree-shaking. However, this changed the imports for these runtime components and services.

Before
import { AlertService } from '@nsx/ngx-ns-core'
After
import { AlertService } from '@nsx/ngx-ns-core/alert'

Expanders 6.6.0

· One min read
Koen De Cock
Koen De Cock
R&D Engineer

Resources

The expansion resources below provide Expanders 6.6.0.

ResourceVersion
Expanders6.6.0
nsx-default-stack2024.2.0

Expander development changes

Expanders 6.6.0 mainly focuses on improvements for Expander development.

Type attribute for uses

Uses statements in mapping file can now have a type attribute. The way the type is resolved in specific to the import strategy.

For java import, you can now add static imports by adding type="static".

  <uses type="static" eval="'net.democritus.sys.NullDataRef.EMPTY_DATA_REF'"/>

@import parameters

The @imports statement in Expander templates can now have one or more parameters. These parameters in case you have multiple types of imports in the same artifact (e.g. in Angular).

Read more.

ExpanderRelocation

There is now support for renaming Expanders, changing packages or changing the artifact location. By defining an ExpanderRelocation DataResource, you can redirect Features and harvest files to the new location, so that everything still works the same way after the change.

Read more.