Customization of Otter project

[kpanot]

Customization of Otter project

One of the purposes of the Otter Framework is to provide a way to customize a web application.
The customization can be seen at 3 different levels:

• Application runtime: customization is applied during the life of the application on user browser. This is set according to end user inputs and can rely on the Content Management level configuration.
• Content Management: customization that can be defined bit business analytics via CMS. It is mainly relative to the application assets setup of metadata based configuration.
• Application customization: customization applied to an application before the build of it. This customization will be embedded inside the application release.

Each level comes with a dedicated set of feature offered by Otter tools (or inner-source tools).

Features per levels

Application runtime

In the Otter environment, the Application Runtime customization are applied to an application by the Rules Engine mechanism exposed by the package @o3r/rules-engine.
Via this mechanism, the customization are applied runtime via Actions resulting of Rules defined by the business analyst at Content Management level.

Currently the actions exposed by the Otter environments is covering the following scopes:

• Placeholder injection: Inject basic i18n supporting HTML components within a predefined places in the application
• Styling rule update: add or remove CSS rules to the application, which can include CSS Variable override or pure CSS rules.
• Localization key switch: map a translation key to another key already defined in the application.
• Assets redirection: map the URL of an assets to another URL and replace the assets already download/displayed in the application.

Content Management

The Otter environment is extracting the metadata of different resources to enable the customization of the resources via a Content Manager System tools (such as Adobe Experience Manager) to be applied to the application bundle before it is deploy to the server.

The following feature are customizable at content management side:

• Assets management: add/replace/remove assets from the bundle to be served beside of the application.
• Styling sheet injection: add additional CSS sheet rules to the application on top of the embedded component styling.
• CSS Variable override: set/override the value of the CSS variable exposed in the metadata.
• Configuration override: override the default value of the component exposed in the metadata.
• Localization: define the translation for the localization keys exported from the application via the localization metadata.
• Rules-ets definition: set of rules to be executed runtime by the rules engine and based on the facts and operators part of the metadata.

Application customization

This customization is currently an inner-source capability only. The main purpose of this level of the customization is to able teams, not working on the code source of the application, to customized a based Otter Application in different points.
The purpose of this capability is to reduce the cost of the development of flavors of an application by reducing the amount of code touched.

The features dedicated to this level of customization is the following one:

• Provider injection: Add custom Angular injectable and load custom Angular module within the application context.
• Component injection: Inject component within an application page template (thanks to html template selector). This feature is limited to pages, not within component.
• Component replacement: capability to replace any flagged component, from the base application, by a new component developed specifically for the customization (or another existing component already part of the base application).
• Locales selection: customize the list of the languages supported, the default one and the labels of each languages.
  • list of supported languages
  • default language
  • fallback language (in case of missing translation)
  • Mapping of the language labels (including area's locals) with the language
• Prefetch configuration: Configure the the prefetch setup of the application (list of assets to prefetch, priority of the prefetch, etc...).
  • List of assets to prefetch
  • Priority rules of the assets to prefetch
• Configuration of build setup: override the full angular.json file to modify the way the base application is built.

Summarize of the feature supports

Summary of the current state of the customization solution with the solution we need to put in place for Otter Applications.

Feature	Covered by Application Runtime solution	Covered by Content Management solution	Covered by Inner-source App Customization solution	To be covered by future App Customization solution
Placeholder injection	✅	❌	❌	❌
Styling rule update	✅	❌	❌	❌
Localization key switch	✅	❌	❌	❌
Assets redirection	✅	❌	❌	❌
Assets management	✅	✅	✅	❓
Styling sheet injection	✅	✅	✅	❓
CSS Variable override	✅	✅	✅	✅
Configuration override	✅	✅	✅	✅
Localization	✅	✅	✅	✅
Rule-sets definition	❌	✅	✅	❓
Provider injection	❌	❌	✅	✅
Component injection	❌	❌	✅	❓
Locales selection	❌	❌	✅	✅
Prefetch configuration	❌	❌	✅	✅
Configuration of build setup	❌	❌	✅	➕

Note

Legends:

• ❌ not supported / not to be supported
• ✅ supported / need to be supported
• ❓ not decided yet
• ➕ optionally supported

Proposals for Application Customization

Application as Custom Application

The concept is to consider an Otter Application generated (part of a workspace) as a potential custom application custom application.
This means to separate the flow from the application to expose it in a library package to minimize the content of application itself.
The purpose of it is to let the application as simple as possible to be able to apply script to facilitate the migration but letting the full flexibility to the custom application.

This would be translated, technically, by the following constrains:

• Exposition of the flow (currently part of AppModule) by the the based application.
• Exposition of mechanism to inject component in package (via build time placeholder?)
• Exposition of component replacement at exposed module level
• Creation of a generator, on top of Angular's ng g application, with the template simplifying the basic customization
• Creation of a generator, on top of Angular's ng g library, To facilitating the conception of flow and the exposition mandatory to cover the required features.

In term of Dev setup, it can be realized by:

• A mono repository containing a library exposing the flow and a custom application generated (not customized)
• An external custom application depending on the package exposing the flow

Customization as dependencies

The concept is, for an application, to depend of a library with an interface exposition the customizations.

This would be translated, technically, by the following constrains:

• Creation of a generator, on top of Angular's ng g library, To facilitating the exposition mandatory to cover the required features.
• Creation of the package providing helpers to apply the customization for the library at build time.

In term of Dev setup, it can be realized by:

• A mono repository containing a customization library with the minimum configuration required and the application depending on the library
• An external customization library

Others

This is the start of the discussion, please feel free to complement and/or add another proposal for the Otter Customization solution.