List of Values (LOV)¶

A dropdown list of references that display values of one or more database columns.

When to use¶

When it is required for the user to select values that are already available in the database.

Properties¶

Below is a list of properties that can be used to customize the control.

Examples¶

Example 1 - Using a Reference and a Selector
Example 2 - Using a query and list for Advanced view
Example 3 - Dynamically changing values
Example 4 - LOV searching
Example 5 - String interpolation
Example 6 - freeinput and wildcard

Example 1 - Using a Reference and a Selector¶


lov CalendarIdRef with CalendarIdRefSelector {  
   size = Small;  
}  

selector CalendarIdRefSelector for WorkTimeCalendar {  
   static CalendarId;  
   static Description;  
   static Objstate;  
}

Example 1: Client file


@Override  
entity LaborClass {  
   reference CalendarIdRef(CalendarId) to WorkTimeCalendar(CalendarId) {  
      label = "Calendar ID";  
   }  
}

Example 1: Projection file

Example 2 - Using a query and list for Advanced view¶


lov LineProgramRef with LineProgramSelector using LineProgramLovs {  
   label = "Program";  
   required = [false];  
   description = LineProgramRef.Description;  
   format = uppercase;  
   maxlength = 10;  
   advancedview LineProgramLovList;  
}  

@DynamicComponentDependency PROJ  
selector LineProgramSelector for LineProgramLov {  
   title = "Program";  
   field ProgramId;  
   field Description;  
}  

@DynamicComponentDependency PROJ  
list LineProgramLovList for LineProgramLov {  
   label = "Program";  

   static Company;  
   static ProgramId;  
   static Description;  
}

Example 2: Client file


@DynamicComponentDependency PROJ  
entityset LineProgramLovs for LineProgramLov;  

@DynamicComponentDependency PROJ  
reference LineProgramRef(Company, LineProgramId) to LineProgramLov(Company, ProgramId);  

@DynamicComponentDependency PROJ  
query LineProgramLov {  
   from = "project_program_lov";  
   where = "objstate in ('Active')";  
   keys = Company, ProgramId;  

   attribute Company Text;  
   attribute ProgramId Text;  
   attribute Description Text;  
}

Example 2: Projection file

Example 3 - Dynamically changing values¶

Instead of always getting the same records loaded into the LOV dropdown, there might be scenarios where you need to show a filtered set of values based on other attributes in the record.

For example, consider a driver who has the license to drive Manual and Automatic vehicles. The driver is allowed to select a vehicle with Manual or Automatic transmission from the list of vehicles. But, a driver who has Automatic only driving license should only be able to pick vehicles with Automatic transmission. It is always good to hide the unavailable LOV options from the user.

To implement this, you can use a function which returns a collection of entities as the data source for the LOV instead of an entity set. At runtime, you can pass values from other attributes as parameters into the function. In the function,you can apply the necessary logic and send back a filtered set of records to the LOV. In this case you have the flexibility of writing any logic to get the correct records out of the function.

Consider the following reference:


reference MainRepresentativeRef(MainRepresentativeId) to BusinessRepresentative(RepresentativeId);

Example 3: Projection file

Create a function in the projection which returns a list of entities. If your requirement is to simply filter the values based on a parameter, you can add a where clause inside the function implementation.


function GetRepresentatives List<Entity(BusinessRepresentative)> {  
    parameter RepresentativeId Text;  
    where = "representative_id LIKE SUBSTR(:RepresentativeId, 1, 1) || '%'";<br/>}<br/>

Example 3: Projection file

If you need to apply more advance logic to filter out values, you can write your own function implementation in the PLSQL file.


function GetRepresentativesCustom List<Entity(BusinessRepresentative)> {  
    parameter RepresentativeId Text;  
}

Example 3: Projection file


FUNCTION Get_Representatives_Custom___(  
   representative_id_ IN VARCHAR2 ) RETURN Objid_Arr  
IS  
   base_collection_ Objid_Arr := Objid_Arr();CURSOR Get IS  
      SELECT *  
      FROM BUSINESS_REPRESENTATIVE  
      WHERE representative_id LIKE SUBSTR(representative_id_,1,1)||'%';<br/>BEGIN<br/>   FOR rec_ IN Get LOOP<br/>      base_collection_.extend;<br/>      base_collection_(base_collection_.last) := rec_.objid;<br/>   END LOOP;<br/>   RETURN base_collection_;<br/>END Get_Representatives___;<br/>

Example 3: PLSQL file

In the client file you can connect the function (together with parameters) in the same way you would connect an entity set with a LOV.


group MainRepresentativeGroup for Activity {  
   lov MainRepresentativeRef with RepresentativeSelector using GetRepresentatives(MainRepresentativeId) {  
      label = "Main Representative Id";  
   }  
}

Example 3: Client file

You can use the same reference with different LOVs, populated using different entity sets and functions. This way, you can make sure that the user will get only the available options in the LOV.

Example 4 - LOV searching¶

When searching in LOVs you will always search for the key value and any extra columns that you declare.


lov Customer with CustomerSelector using Customers {  
   description = CustomerName;  
   preview = CustomerInfoCard;  
   search = Name, Party;  
}

Example 4: Client file

In this example the search will be done on the key value column (CustomerId), Name and Party.

Typing for example "McLa" in the control would generate a filter that looks like this $filter=contains(CustomerId,'McLa') or contains(Name, 'McLa') or contains(Party, 'McLa').

You can add one or more columns and they will be added to the search condition when typing in the control. These columns should exist in the entity you search.

Example 5 - String interpolation¶

String interpolation can be used to present the user with a custom description text.


lov Customer with CustomerSelector using Customers {  
   description = "${Customer.CustomerName} ( ${Customer.Party} )";  
}

Example 5: Client file

Example 6 - freeinput and wildcard¶

The freeinput property allows the user to enter a value that does not exist in the reference. The value typed in the field will be stored in the relevant attribute, no matter if it exists in the list or not.


lov Customer with CustomerSelector using Customers {  
   freeinput = [true]  
}

wildcard can be considered as a more restricted variation of freeinput where the user can specify a predefined value that does not exist in the LOV.


   lov ReportCostRef with ReferenceReportCostLov {  
      search = ReportCost, Description;  
      description = ReportCostRef.Description;  
      wildcard {  
         key = "%";  
         description = "All";  
      }  
   }