Core Engine (3.10)

# Layouts and Renderer Fallback Mechanism

For each view in the 4ALLPORTAL, a separate layout or object renderer XML in the file system is required. When requesting the corresponding configuration, the system follows a fallback logic.

# How Are Layouts and Object Renderers Requested?

For each view, the system checks the corresponding folder path in the file system to get the required .4aplayout or .4aprenderer configuration for displaying the correct GUI. Every time a specific layout or object renderer is required in the GUI, it must be stored in the corresponding path.

Examples:

  • A user opens tab Evolution Tree in the Files module. The according .4aplayout is requested from here: modules/file/layouts/evolution_tree
  • An admin opens admin snap-in General system configurations/User settings/Security to define the password security. The according .4aprenderer is requested from here: modules/user/object_renderer/metadata/admin.

If no specific file can be found at the requested path, the system follows the fallback logic.

# Default Folder-Based Fallback

Using fallbacks and referring to default configurations makes it unnecessary to store a separate XML for every single required view. For default views or renderers, also a default.4aplayout or default.4aprenderer can be referred to. They are stored in a way the fallback logic will request them. This logic makes it also impossible to not load a layout or object renderer configuration.

The fallback logic always starts from the folder path of the requested layout or renderer. It then works its way up looking for the first full configuration XML (in most cases, a default), alternately in the corresponding global/defaults folder, then in the next higher module folder.
This basic logic is used for both layouts and object renderers.

Example: A layout is requested for view modules/user/layouts/main/special_main, but this folder does not exist. For a layout, the system now checks:


folder-based fallback

As soon as a full layout XML is found, it will apply and the fallback stops.

The system checks the runtime folder. From version 4.x on, the fallbacks considers the system's app order (more details).

# Fallback with Changes, Attributes, and IDs

In most cases, the requested configuration results in a default.4aplayout or default.4aprenderer. These defaults can be customized or complemented by:

All these are preferred to a default. and will affect the fallback.

# Configuration Changes Fallback

A configuration change (_c) is a configuration supplement and alters a full configuration XML. When requesting e.g. a search renderer, there may only be a change XML stored in the corresponding renderer path in the file system.
The next full search renderer XML is determined following the fallback logic. To that, the change XML from the requested path applies and alters the full configuration.

Examples:

A metadata renderer for the Files module is requested from here: modules/file/object_renderer/metadata. This path contains two files:

  • default.4aprenderer
  • default.4aprenderer_c
    Result: The _c file will apply to the next full renderer XML, which in this case is stored in the same folder.

A layout for the User module is requested from here: modules/user/layouts/main/admin. This path contains one file:

  • default.4aplayout_c
    Result: The _c file will apply to the next full layout XML, which in this case is determined here: global/defaults/layouts/main/admin.

Please note: This behaviour will change with Core Engine version 4.0 (more information).

# Attribute-Based Fallback (Role, ObjectType, ClientType)

With attributes, a layout or object renderer can be defined for certain roles or use cases:

  • ro_ defines a configuration as role-specific (e.g., for admins only)
  • ot_ defines a configuration as objecttype-specific (e.g., for videofiles only)
  • ct_ defines a configuration as clienttype-specific (e.g., for smartphones only)

When requesting e.g. a layout, there may be an attributed XML stored in the corresponding path that only applies for the defined role/use case. If this file is a full configuration, it applies. If it is a change file, the folder-based fallback applies to determine the next full layout or renderer configuration.

Examples:

A metadata renderer for the Files module is requested from here: modules/file/object_renderer/metadata. This path contains these files:

  • default.4aprenderer
  • default.4aprenderer_c
  • ot_audio.4aprenderer_c
  • ot_image.4aprenderer_c
  • ot_indesign.4aprenderer_c
  • ot_video.4aprenderer_c
    Result: An ot_ configuration applies if the corresponding renderer is requested (e.g. ot_audio.4aprenderer_c for an audio file's detail view). It is a _c file, and a full configuration XML must be determined by the folder-based fallback logic. In this case, default.4aprenderer is stored in the same folder (which itself was altered by the default.4aprenderer_c change XML).

A layout for the Tasks module is requested from here: modules/task/layouts/detail. This path contains these files:

  • ro_detailslim.4aplayout_c
  • default.4aplayout_c
    Result: The ro_ configuration applies if the renderer is requested from a user of the mapped role. It is a _c file, and a full configuration XML must be determined by the folder-based fallback logic. In this case, from here: global/defaults/layouts/detail. The default.4aprenderer_c in this folder will apply for all roles that were not mapped to this special layout.

For more details on role specific layout mapping, refer the layouts documentation.

# Unique Folder or Filename IDs

If a special (not default) layout or object renderer is required unrestricted by ro_, ot_, or ct_, it can be stored in a unique folder (recommended) or given a unique name (id_).
This configuration is requested only for this special view and has no corresponding structure in the global folder for a fallback.

Examples:

A layout for tab Evolution Tree in the Files module is requested from modules/file/layouts/evolution_tree. This path contains file:

  • default.4aplayout
    Result: Since it is a full configuration XML, this layout will apply.

A layout for tab Evolution Tree in the Files module is requested from modules/file/layouts/detail. This path contains file:

  • id_evolutiontree.4aplayout
    Result: Since it is a full configuration XML, this layout will apply.

Please note: The folder-based fallback to a default still works, though, and secures a configuration is available in case of a broken ID configuration.

# Attribute Combinations and Scoring

Attributes can be combined, e.g. to provide client-dependent views for a specific role (ct_video.ro_admins.4aplayout).
In case of multiple attribute configurations in one folder or when fallbacking, the system works with a scoring to determine the valid one:

  • id scores 8
  • ro scores 4
  • ct scores 2
  • ot scores 1

Example: ot_image.ct_phone.ro_user.id_special_view.4aplayout
If all attributes match, the score would be 15. If all attributes but ot_ match, the score would be 14.

Change files _c follow the same scoring. They will be preferred, though, if the score is equal.

# Fallback from Runtime

When fallbacking, the system checks the global and module's folders in the runtime, which means the defaults, changes and customizations are not 4App-specific. Configurations will be overridden by configurations with the same filename in another module's or the custom folder.

# Fallback With Multiple Changes

This behaviour will change with Core Engine version 4.0, when multiple changes are supported: The system will then know which 4App a configuration comes from and will apply it according to the system's app order, following this hierarchy:

# App Hierarchy With Multiple Changes

For providing the requested configuration, the system checks the corresponding path in all installed 4Apps including the customizations from the custom folder:

  • Core Engine (applies first)
  • all other 4Apps according to the system's app order
  • Custom folder (applies at last)

If the required folder can be found in all these places, the requested configuration (e.g. default.4aprenderer) will build up on one another.

For further information, refer to our changes documentation.

← Metrics →

Request missing documentation