Migration of Component Templates and Attached Components

In Uniface 9, component variables were separate objects that were not inherited.

In Uniface 10, component variables are defined in the Declarations code container, so they are inherited by the derived component.

In Uniface 9, entities and fields in component templates were defined as generic if the entity was part of the UGENERIC model, the default for entities created in a component template.

In Uniface 10, they are created as non-generic objects by default, either derived from modeled entities and fields, or copied from templates as non-derived objects.

To make an entity or field generic, you need to explicitly set its Is Generic property to True.

Modeled components that have been migrated from Uniface 9 have these properties correctly set.

In Uniface 9, a wizard was used to bind generic entities and fields to target objects in the attached component. Once bound, it was not possible to bind to a different object.

In Uniface 10, generic entities and fields in the modeled component become bound entities in the derived component. The Is Bound property is set to True and the generic entity to which it is bound is defined in the Bound To property.

Initially, they are bound to an object with the same name as the generic object, but you can bind to another object simply by renaming the bound object. The bound object's Bound To property always specifies the name of the generic object from which it was copied. This ensures that Uniface can generate the correct name references to the bound entities and fields.

In Uniface 9, implicitly-defined constants were used to bind entities and fields to their generic counterparts. They also made it possible to write generic ProcScript.

Uniface 10 uses a different binding mechanism so it is possible to change the binding. To ensure that you can write generic code, implicit constant mappings are still used. They are generated for each entity and field in the derived component's structure when it is compiled.

During migration, implicit constant mappings are made explicit by adding them to the Declarations container of migrated derived components. They ensure that existing generic ProcScript continues to work, even if it references a field that is not in the component structure of the derived component. However, these explicit constant definitions override Uniface 10's default name resolution process.

If you want Uniface to automatically handle references in the migrated derived component, you can set the migration logical MIGRATION_REMOVE_MAPPING_DERIVED_COMPONENTS = 1 in the ide.asn file prior to migration. Alternatively, you can review and remove unneeded definitions from the Declarations container after migration.

When compiling Uniface components, if there are multiple definitions for the same constant, the one that is actually used depends on the compilation order. In Uniface 10, the compilation order has changed.

In Uniface 9, internal and user-defined constants were declared in different containers, resulting in the following compilation order:

1. Component template internal constants
2. Attached component internal constants
3. Component template user-defined constants
4. Attached component user-defined constants

In Uniface 10, all constants are declared in the Declarations script container, whether they were user-defined or internal constants. The compilation order therefore depends on the order in which they are defined and their location:

1. Modeled component Declarations container
2. Derived component Declarations container