Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

> ## Using mapped fields

> You can use the mapped field feature when there is a dynamic lookup on a viewer and you must display extra information on the viewer for the selected or displayed lookup record. In this case, you can add a field to the viewer and link this field to a selected field in the lookup browser that displays when a selection is made.

> For example, you can modify the CustomerCodeLookup in the order viewer that you build as part of the Progress Dynamics tutorial using the `dynsports` database. (For more information on this tutorial, see OpenEdge Development: Progress Dynamics Getting Started .) For the tutorial, you create this lookup on the fill-in for the customer object field (`customer_obj`) that you generate as part of the dynamic viewer (`artorviewv`) for `art_order`. For a given order, this lookup displays the customer name that you select from the lookup browser with a query on `arm_customer`. The lookup browser displays both `customer_code` and `customer_name` for each `arm_customer`, and the lookup also contains a link from `customer_balance` to a fill-in (fiCustBalance) that you create on the viewer so the balance can be displayed for the selected customer.

> ##### Preparing the lookup for field mapping

> In the tutorial example, CustomerCodeLookup uses three fields from the query on `arm_customer`:

> - `customer_balance`

> - `customer_code`

> - `customer_name`

> In order to avoid AppServer requests when displaying the fields used by a lookup, you must map all of the fields used in the lookup query to the viewer data source (SDO), including the displayed field, all fields specified for the lookup browser sequence, and any specified linked fields. For this example, you must map the three lookup fields to corresponding fields in the SDO for `art_order` (`artorfullo`). Because the tutorial generates the `artorfullo` SDO as a data source for `art_order` only, you must explicitly add the `arm_customer` fields for the lookup to this SDO.

> | To add the arm_customer fields to the lookup:

> 1. Modify the SDO to join `art_order` to `arm_customer` (on `customer_obj`, by default).

> 2. Add the fields from arm customer to the SDO like this:

> - `customer_balance` — Not updateable.
> - `customer_code` — Not updateable.
> - `customer_name` — Updateable.

> ##### Mapping lookup fields to the SDO

> You can map the lookup fields in the following ways:

> 1. Linking lookup fields directly to SDO fields on the viewer

> 2. Mapping lookup fields to SDO fields through viewer widgets

> These two options essentially provide the same results at run time. However, for cases where you cannot use the first option, you can use the second option to get the lookup data from the SDO.

> In the example from the tutorial, you can use either option. However, the first option produces a less practical result, with an extra (and redundant) field on the viewer.

> Note: Dynamics only uses the field mapping mechanism when records are being displayed from the data source. If the user changes a lookup’s value, the default behavior for retrieving these values (from the AppServer) executes. However, the mechanism still improves performance and reduces AppServer requests.

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