37 posts tagged with "migration-guide"

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)

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.

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.

{
  "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.

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.

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.

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

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.

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

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

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.

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​

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.

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

Migration guide​

Branding​

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

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.

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.

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

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

Changes and improvements​

This update contains a lot of improvements for wiring capabilities, making it easier to reuse expanded elements in custom pages.

List page refactored​

The expanded list page has been updated to use the new table with multi sort capabilities. The table is extracted from the page component and resides in its separate DataViewTable component. It now uses the upgraded filter component, that is generated based on the QuerySearch setup. Filtering state between the ngx-ns-core component and the generated dropdown form is managed by the new DataConnectorFilterSource service. Instead of managing the pagination, filtering and sorting manually in the list component, a DataConnectorDataSource service has been introduced to make this easier.

Table refactored​

Breaking change: Existing components nsx-table, nsx-table-column and directive [nsxTableCell] have been replaced with counterparts from the ngx-ns-core library.

The table now has multi sort capabilities, supports sticky headers and columns, and accepts a NscDataSource as well as data arrays.

Paginator refactored​

Breaking change: Existing component nsx-paginator has been replaced with counterpart from the ngx-ns-core library.

Filter refactored​

Breaking change: Existing component nsx-table-search has been replaced with counterpart from the ngx-ns-core library. The filtering capabilities have been upgraded.

Changes and improvements​

Upgrade to Angular 17 and Angular Material 17​

In the previous release (4.1.x) we upgraded to from Angular 14 to 16, but used legacy Angular Material 14 components. Now we have upgraded completely to the latest 17 version.

Breadcrumbs refactored​

Breaking change: in routing change name and isBreadcrumb data entries to breadcrumb. The former is replaced by breadcrumb and the latter has become obsolete.

Styling setup refactored​

Breaking change: _theme-to-material-component-exposer.scss has been replaced with _theme-to-component-exposer.scss. Material expose mixin _theme-to-css-classes-exposer.scss has been deleted. Behaviour can be re-added custom if wanted.

Switch to Material symbols​

We switched to Material symbols instead of Material icons as default icon font set.

Added use of Angular library​

Created the ngx-ns-core library containing runtime components, services and directives. Some of the expanded components and services have already been migrated, e.g. sidebar, top-bar, breadcrumbs, etc.

Changes and improvements​

Migrating to QuerySearch metamodel​

Since version 3.x of rest-expanders, which was released just over a year ago, rest-expanders has integrated with querysearch-expanders by using the QuerySearch metamodel. This was introduced in such a way that it was 100% backwards compatible and also added to the model when expanding implicitly, so no change could really be observed from the perspective of an application developer.

Today the QuerySearch metamodel has matured to the point that what currently exists of the model is stable and will no longer have any big structural changes that are not additive. So with this version of rest-expanders, the implicitly added model will be removed. This means that it has to be defined in the model by the developer and coupled to the rest-expanders using the relevant jaxrs.querySearch option that has been implicitly used for quite some time.

The transmuters to add default REST APIs to the model have been modified to do this automatically, so in that sense, there will be no change to the way of interacting with rest-expanders in the majority of cases.

DataCommand options​

In rest-expanders version 3.8.0, options were introduced to mark the DataCommands that are to be used for the CRUD operations in the REST API. Starting with this version, the validation to check if this has been migrated has been removed, as well as them being implicitly added to the model. We assume that every project has been migrated by now, but this will be the last version where the Upgrade transmutation for rest-expanders does this migration automatically.