42 posts tagged with "migration-guide"
View All TagsAngular Expanders 6.0.0
Changes and improvements
Upgrade to Angular 19 and Angular Material 19
For this release we updated all the code to Angular
19, in order to stay up to date with the releases and best practices.
Separation of QuerySearch
QuerySearch is now an addon, instead of the default filtering implementation.
Everything related to filtering in the code has been moved to separate expansionResources
, namely angular-querysearch-expanders
, angular-svcapi-querysearch-expanders
and angular-stdapi-querysearch-expanders
.
When these expansionResources
are not added the application will still function, however the filtering capabilities will not be present.
From now on you can also add filtering implementations, e.g. finders, or provide a custom one.
Yarn support
We provide a solution to substitute npm
with yarn
if wanted. This drastically improves dependencies install times. Substitute the Std API
profile with Std API yarn
(or Svc) in your expansionSettings.xml
.
Harvest expanders
The angular-expanders
now depend on the harvest-expanders:1.0.0
, this is an example of one of the first expansionResources
that contains reusable expanders. These expanders and expansion steps define the gen/ext
less harvesting.
New design implementation
This version contains the new designs made for the list and details page.
Angular Expanders 5.6.0
Migration guide
Program folder refactor
In order to accommodate multiple AngularApp
instances, a folder structure similar to Application
has been adopted. This means that in the angular
folder you should relocate the ext
, harvest
and model
folder present to a subpath /angularApps/{angularAppName}
. You should not move the featureModules
folder.
angular
├── ext
├── harvest
├── model
. └── space-app.xml
angular
├── angularApps
. ├── space-app
. ├── ext
├── harvest
├── model
. └── space-app.xml
Changed allowed value of option angular.isLinkFilterField
The expanders were refactored to correctly find the required DataConnector
in the available dataConnectors of the AngularApp
. A new find algorithm has been put in place to do this, this algorithm does not rely on the DataRef
anymore. This is why the value of the option has been changed to only the name of the DataConnector
.
featureModuleName::dataConnectorName
dataConnectorName
Branding
Login component
Due to popular request the generated login component can be fully customised when using the option angular.hasCustomBranding
. This will now give you custom anchors in the login.component.html
and login.component.scss
files, instead of only the option to change the images.
Title tag in index.html
When using the option angular.hasCustomBranding
, custom anchors will appear to set the title tag of your index.html
. This is used in the browser tabs, when no other title is set via the angular router. When not filled in, it will put the url in the browser tab. Before the title was always angularAppName
.
Docker TomEE base image 3.0.0
Version 3 of the nsx-tomee-base Docker image is now available. This version introduces (experimental) support for rootless containers, as well as some minor breaking changes.
Rootless
New images have been added that can be used to run rootless containers. They add a new tomee
user, which is used to
execute the TomEE application server instead of the root
user. Not running containers with a root
user reduces
security risks for the host system. All existing images are available as rootless as well under labels with the
suffix -rootless
appended to it.
Data volume
The image now pre-defines a volume at the /data
path for applications to write files to. The volume is pre-defined so
it will be created even if it is not explicitly defined in the deployment of the container, so any files stored there
will always be put into a persistent volume.
Scripts moved
Previously all fixed scripts were stored in the /tmp
folder. Though this is not ideal, we kept this for consistency
and backwards compatibility. With this major version we've now moved those scripts to a new location in /scripts
.
There are still symlinks to the existing scripts in case they were called.
Process Automation 1.7.0
A brand-new release of the process-automation component is now available! There have been quite a few changes, mostly targeting stability, compatability and bug fixes. Some of the default configuration has changed, which may impact applications using a custom configuration. Read the migration guide below to verify if this applies to you!
Changes and improvements
- (Stability)
{DataElement}Cruds
will now return an error when trying to modify an element into an interim state outside a Task. - (Stability) Added error and recovery policies, allowing applications to configure how to deal with internal errors.
- (Stability) Fixed some issues which would occur when transactions went into timeout.
- (Compatability) Added support for applications using the
ejb.interfaces.localOnly
option. - (Compatability) Replace usage of TransactionManager with TransactionSynchronizationRegistry. This should be available in more JavaEE runtimes.
- (Traceability) Added new monitoring anchors, to allow for more insight into applications running in production (more on this soon).
- (Performance) ApplicationPersistent queue will now fetch the queue much sooner if the last fetch received the requested number of tasks.
Angular Expanders 5.0.0
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 4.26.0
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
.
Resource | Version |
---|---|
rest-jaxrs-stack | 4.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.
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
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.
Angular Expanders 4.5.0
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>
QuerySearch Expanders 2.26.0
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.