T24 User Guide - Page 13

Loading ...

T24 Application Development

Virtual Tables

The concept of virtual tables has been added to prevent the growth in the number of simple tables that

are shipped as part of T24 which serve only to provide a list of options that Temenos cannot hard

code, e.g. statuses, titles, etc.

Rather than create a new table for each of these, a virtual table can be defined.

VIRTUAL.TABLE.LIST = ''

VIRTUAL.TABLE.LIST = 'VIRTUAL.TABLE'

CALL EB.LOOKUP.LIST(VIRTUAL.TABLE.LIST)

The variable VIRTUAL.TABLE.LIST can then be used to directly populate the T array directly:

T(Z) = VIRTUAL.TABLE.LIST ; * List from EB.LOOKUP

The actual items for the virtual table are defined on one table, called EB.LOOKUP. The key to this

table is VIRTUAL.TABLE.NAME*REAL.KEY, e.g. EB.STATUS*COMPLETE.

The list populates the second field of the T array, such that a list of the available options is available to

the user without need to use a dropdown. EB.LOOKUP contains additional fields in a name – value

pair structure that may be used to contain parameter information. Refer to the help text on

EB.LOOKUP for more information.

Operations

Provision has been added to allow OPERATION style fields to be defined. The concept is that a

trigger field is used to determine the action that is being performed, and depending upon that action

certain fields in the application will be made available for input while others will become no input. This

concept has existed in T24 applications for some time (e.g. in the LC and PD modules) and now

support has been added to the template.

Firstly, a field must be defined that holds the options, and should be named OPERATION

Z+=1 ; F(Z) = "OPERATION" ; N(Z) = "35" ; T(Z) = "" ; T(Z)<2> = 'ACCEPT_REJECT'

The property

Table.Trigger is used to store which field will act as the trigger for the operation

process, and should be set to the equated field name:

Table.Trigger = MY.APP.OPERATION

There are two further properties that are used to control which fields will be made available for input,

and which fields will be set to no input. Each property takes a value mark (

VM) delimited list of fields.

ACCEPT.FIELDS.NOINPUT = MY.APP.REJECT.DATE : VM : MY.APP.REJECT.REASON

REJECT.FIELDS.INPUT = MY.APP.REJECT.DATE : VM : MY.APP.REJECT.REASON

accept = 1

reject = 2

Table.inputtableFields<reject> = REJECT.FIELDS.INPUT

Table.noInputFields<accept> = ACCEPT.FIELDS.NOINPUT

In the above example, the fields REJECT.DATE and REJECT.REASON will be no input when the

ACCEPT operation is selected – all other fields will behave as defined in the T array. When the

REJECT operation is selected, only the REJECT.DATE and REJECT.REASON fields will be available

for input – all others will no input. If both properties are set for an operation, the C_NOINPUTS

property is ignored. NB If we are processing a NOINPUTS list, then any field that is already defined as

NOINPUT, NOCHANGE, etc. will retain that definition to prevent reserved fields, etc. being made

inputtable! The variables accept and reject refer to positions in the list of allowed operations

(

T(Z)<2>).

TEMENOS T24 User Guide Page 13 of 34

Loading ...