Extension Points

Overview

Extension Points allow one module to insert additional elements (such as fields, actions, consumers, filter extensions, view templates, or view references) into data models owned by another module without changing the original source. This preserves modularity and avoids conflicts in shared models. Inserted elements appear exactly at the defined Extension Point position in the model rather than being appended at the end as with generic modifications.

tip

Extension Points are the correct approach to edit other modules.

When to Use Extension Points

When multiple modules collaborate, a module often needs to extend structures defined elsewhere. Extension Points designate explicit insertion locations for such extensions.

Benefits:

• They prevent merge conflicts by avoiding direct edits in foreign modules.
• They enable reuse and tailored customization of shared modules.
• They preserve upgrade ability and backward compatibility.
• They provide precise control over the position of inserted elements.

warning

Extension Points are compile-time injection markers resolved by the ADITO transpiler. They are not runtime hooks.

Therefore, add Extension Points to a data model only in the module that defines that model. If the data model is extended from another module, use the existing Extension Points. Do not create new Extension Points in the module that extends the model. Extension Points should not be used to group your customer-specific elements, instead you should use the existing Extension Points to insert your elements.

If no suitable Extension Points exist, contact the original module author to add them. You should double-check with them how and when to extend their data models. The module author may not be aware of the need for Extension Points, or they might consider this data model as "final" and therefore not open for extension.

Think of Extension Points as contracts offered by a lower-level module that define where and how existing elements may be extended.

Responsibilities of Module Authors

Module authors are responsible for providing well-placed Extension Points to enable controlled extensibility of their entities and views. The number and location of Extension Points should be enough to cover common extension scenarios without fragmenting the model.

danger

Module authors should not rename or delete existing Extension Points. Other modules will relay on those existing Extension Points. If you refactor an existing Extension Point, you will break existing modules and their modifications.

If you must change an existing Extension Point, communicate the breaking change to all module consumers. Without any notice, your refactoring can break their code.

Supported Extension Point Types

Extension Points can be defined in both View and Entity models.

• Views: Implementations include ViewTemplates and ViewReferences.
• Entities: Extension Points can target common child elements, and in RecordContainers they can focus on FilterExtension and FilterExtensionSet.

Modifications and Build Integration

All extensions implemented via Extension Points are stored in the extending module as a modification. The source of the extended module remains unchanged. During transpile, the system collects these modifications and injects them into the original models. The output is a flattened, deployable structure in the dist directory.

includeInBuild Flag

Each Extension Point provides an includeInBuild flag.

• true (default): The Extension Point and its implementations are included in the build.
• false: The Extension Point and all its implementations are excluded from the build.

Use this flag to temporarily disable features, for example, in customer-specific builds.

tip

Set includeInBuild to false to disable specific extension areas without deleting or restructuring them.

The includeInBuild flag is evaluated during transpile:

• The Extension Point and its implementations are omitted from the build output.
• No .aod fragments are produced for this Extension Point.
• Referencing model elements ignore the absence of the Extension Point.

Typical use cases include temporarily disabling customer-specific functionality, hiding unfinished features during incremental development, and conditional release pipelines.

warning

Ensure no runtime logic assumes the presence of an excluded Extension Point; otherwise references to missing elements may fail at runtime.

Extending Without an Extension Point

It is technically possible to extend a foreign model without using an Extension Point. The Designer still creates a modification, and the transpiler resolves it.

warning

Avoid this approach whenever an Extension Point is available. It obscures where extensions are applied and disables fine-grained build control via includeInBuild.

If no suitable Extension Point exists, coordinate with the module author to introduce one.

One-sided Extension Points (Anti-Pattern)

Avoid creating and implementing an Extension Point in the same module ("one-sided Extension Points"). This practice undermines the purpose of Extension Points and should not be used:

• It reduces Git traceability: many unrelated implementations accumulate in a single file instead of being isolated per added elements, making reviews and history analysis harder.
• It breaks the Extension Point principle: clear contracts should be defined in subordinate (extending) modules; the defining module should not also host the implementations.
• It misuses Extension Points as grouping containers: Extension Points are cross-module insertion contracts, not local organization tools.

warning

Use Extension Points only to define cross-module insertion contracts. Keep implementations in dependent modules, not in the module that declares the Extension Point.

Examples

Creating Extension Points

The following procedures describe how to create Extension Points in entities, RecordContainers, and views.

warning

Extension Points should be only created in the module where the data model is originated.

Creating an Extension Point

note

The example references a Field Extension Point. The flow is similar for other view and entity-level Extension Points.

For FilterExtension and FilterExtensionSet Extension Points you need to navigate to the relevant RecordContainer.

1. Open the target entity.

2. Right-click the entity's root folder or the Fields folder and choose "New Extension Point".

   
   Figure: Creating an Extension Point at entity level

3. Select the required type. The dropdown reflects the valid element types that can be implemented by this Extension Point. Provide a clear, descriptive name. Do not keep the default name. A specific name makes future additions easier and avoids unclear names when multiple Extension Points are present.

   
   Figure: Selecting the Extension Point type and name

4. Verify that the Extension Point appears in the navigator.

tip

Views often contain multiple Extension Points. Use explicit, unambiguous names to indicate intent and position.

Adding Implementations

Implementations attach concrete elements to an Extension Point. They are stored as modifications in the implementing package and are merged during transpile.

note

This example demonstrates adding a field to an entity via a Field Extension Point. The behavior is the same for other Extension Point types.

1. Navigate to the entity containing the target Extension Point.

2. Right-click the Extension Point and select "Add Implementation".

   
   Figure: Adding an implementation to an Extension Point

3. Define the new field as you would in a local entity. The Designer stores the resulting EntityField insertion to the extension point as a modification in your package.

After transpile, elements appear in the defined order. With multiple Extension Points, you can position elements before or between existing sections of the view or entity.

Transpile Behavior

During transpile the system:

1. Collects matching Extension Point implementations from dependent modules.
2. Injects additional definitions into the final model within the dist directory.

The result is a deployment-ready model that combines base elements with injected extensions.

Resulting Benefits

Using Extension Points results in clear separation of concerns, safer and upgradeable customization paths, and transparent control over which modules provide which extensions. To review current changes, inspect your module's modification directory or compare the merged model in dist after transpile.