Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

> ## Joining customizations to the SmartObject table

> The customizations by themselves do not affect the application. The key data relationship here is between the `customization_result` table and the `SmartObject` table. This is where the run time effects of the customizations are defined.

> As we noted in the discussion on the SmartObject table, the unique key for that table (beyond its object ID) is not just the `object_filename`, but also the `customization_result_obj` field. For the standard object behavior, the `customization_result_obj` is 0. For customized behavior, it is joined to the `customization_result` table using this field. This means that there must be a distinct `SmartObject` record for each customization result code that applies to the object. If a viewer, for example, has been customized to have different behavior (such as different field positions or different fields enabled or displayed) for each of six different user categories and three different user interface types, such as GUI, CUI, and WBS, then there will be a total of ten `ryc_smartobject` records representing that one object: one for the default definition, six for the user categories, and three for the UI types.

> Each of these `ryc_smartobject` records will have its own set of `attribute_value` records that define it. The SmartObject record with no `customization_result_obj` will define all the default attribute values. Each of the other SmartObject records will define only whatever specific attribute values have been modified for that customization. Thus, the SmartObject records with a `customization_result_obj` are incomplete and cannot be used by themselves to build the object at run time. Their values can only be applied to modify the base attributes defined by the default SmartObject record.

> At run time, the Customization Manager determines the result codes that apply to the session for each customization type by running the functions defined in the `customization_type` `API_reference_name` field. This yields a delimited list that remains available for the remainder of the session. The Repository Manager then combines the various attributes joined to all of the applicable SmartObject records. It does this by using the result code list to identify which `customization_result` records to join to the SmartObject table to retrieve all the applicable `attribute_values`. If multiple customizations apply, a function called `getSessionResultCodes` in the Customization manager determines the priority of them. Those with the highest priority are applied last, so that they take precedence if there are conflicting values for other customization types.

> For example, suppose that user George logs in to a Progress Dynamics session running on WebSpeed using the new browser-based Progress Dynamics UI. George is a data entry clerk. Three result codes apply to this session:

> - `User`: George

> - `UserCategory`: Clerk

> - UIType: WBS

> Suppose that this list represents the priority order of the customization types. (Customization type priority can in fact be defined and modified by session type.) When George runs a dynamic Customer Maintenance window as part of the application, a viewer inside the window has been customized in the following several different ways:

> - George requested that the tab order of the fields be modified so that the data entry process for the Customer Comments field and the Contact field are more convenient for his data entry routine. He also requested that the Comments editor be made larger.

> - George’s group manager defined a customization to the same viewer to disable the Contact field for clerks.

> - The Web application customization chief determined that the Comments editor for the dynamic HTML interface should be made smaller to look better in that environment.

> The result of all of this is that:

> - The Comments field tab order is set as George requested it.

> - The Contact field tab order is irrelevant because the field is disabled for George as a clerk.

> - The size of the Comments editor is determined by the WBS definition because that takes precedence over George’s personal request that is defined at the user level.

> Customizations can be defined only for attributes of SmartObject records, not directly for individual instances. However, you can define customizations at the level of a container window, which can be a way of accomplishing the same thing. In other words, the customizations are always done starting at the level of a SmartObject record. If that SmartObject record represents a container window, then it points to not only its `attribute_value` records, but also to `object_instance` records and their links and page records. Customizations can be done to the container by adding objects to the container or by modifying the attributes of objects inside the window for that window customization.

> Figure 8–18 shows some of the records involved in defining these relationships.

> Figure 8–18: Customization example

> Figure 8–18 illustrates the following customization:

> - George is a clerk, and customizations have been defined for the `UserCategory` `Clerk`, one of which is that the `Customer` viewer`customerviewv` has a height of 12 rather than its default height of 10.

> - When George logs in, the Customization Manager assembles a list of all the appropriate result codes for his session. One of those is for `UserCategory`. The customization table defines a `customization_reference` for `George` for the `UserCategory` `customization_type` that maps to the result code `Clerk` in the `customization_result` table. As a result, the Customization Manager stored `Clerk` as the session result code for the `UserCategory` type.

> - When the system goes to run a window using the `customerviewv` viewer, the Repository Manager must build a list of all the viewer’s attributes. To do this, it locates all the SmartObject records that apply for this session for the viewer. In this case, that means both the default SmartObject, with no `customization_result` code, and also the SmartObject with the `customization_result` code for `Clerk`. It applies all the standard attribute values for the default version of the SmartObject (including the `MinHeight` value of 10), and then applies the attribute values for the customization, one of which overrides the `MinHeight` and sets it to 12. These values are then sent to the Layout Manager to use to build the window.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095