Supply function

Each context node of a controller can be assigned a supply function. This supply function is called by the runtime when the data of the context node is used. This is the case when a UI element is to be displayed for the first time with the data of the corresponding context, for example.

In general, the supply function is called when one or more elements of a context node are accessed and when

the context node is not filled yet or is initial, or
the context node has been invalidated in a previous step.

Supply Functions of Singleton Nodes

The supply function is particularly beneficial when used with Singleton Nodes: The values of elements of a subnode of type Singleton depend on the element of the parent node that holds the lead selection at this point in time. If the lead selection is changed by the user, the supply function can access the new lead selection element and recalculate the values of the subnode elements accordingly. For more information on the concept of singleton nodes and multiple context nodes, see Context Nodes: Properties.

The following example explains how to use the supply function of a singleton node.

Example: Element-Based Detail Display

A list of all available airline carriers is displayed in a table view called Carrier. To do this, the UI element of the type Table is bound to a context node which is filled in the method WDDOINIT of the view controller using an appropriate method. The method WDDOINIT is called when the application is executed for the first time and the data for the table elements is visible for the user at the time of the first display on the screen.

A second table (Connections) displays all flights offered for a specific airline carrier according to the selected element in the first table. The user can select any line in the first table and find the corresponding detail information in the second table. The second table must be filled according to the selected airline carrier, but the view must not be wholly recreated for each selection.

The structure of the context view is as follows:

The first table (Carrier) is bound to the context node CARRIER_NODE, the table Connections is bound to the context node CONNECTION_NODE. When calling the application for the first time, the WDDOINIT method fills the top node with all elements of the database table SCARR which is a list of all airline carriers, their IDs, and the URL of the corresponding homepage. The lead selection of the context node has been automatically created on the first element of the node, and the airline carrier at the top position of the table is the lead selection element.

All flights available for the airline carrier on the lead selection position are listed in the table Connections. The context node CONNECTION_NODE to which the second table is bound is filled by the supply function GET_CONNECTIONS from the database table SPFLI. The lead selection element of the Carrier table is read and all connection information on the corresponding airline carrier are displayed:

When you select another table element as the lead selection in the table Carrier,

the content of the table Connections automatically changes:

Supply Function of the Context Node CONNECTION_NODE

You can only create such a view when the lead selection element of the node CARRIER_NODE is read in the supply function of the node CONNECTION_NODE:

 
  method GET_CONNECTIONS .
 
  data: CARR_ATTR type IF_MAINVIEW=>ELEMENT_CARRIER_NODE,
        FLIGHTS   type SPFLI_TAB.
 
* get filled structure for parent node
  PARENT_ELEMENT->GET_STATIC_ATTRIBUTES( importing
                                        STATIC_ATTRIBUTES = CARR_ATTR ).
* get connections from helper class
  FLIGHTS = CL_WD_GET_SPFLI=>GET_FLIGHTS_BY_CARRID(
           CARRID = CARR_ATTR-CARRID ).
 
 
  NODE->BIND_ELEMENTS( FLIGHTS ).
 
endmethod.

An internal variable of the type of a context element of the parent node CARRIER_NODE and another internal variable of the Dictionary type SPFLI_TAB are declared.
The attribute values of the lead selection element of the parent node CARRIER_NODE are then passed to the internal variable CARR_ATTR.
Note For this transfer, each supply function uses the parameter PARENT_ELEMENT of the reference type IF_WD_CONTEXT_ELEMENT.

PARENT_ELEMENT is a reference to the lead selection element of the parent node of the current node. The parameter is automatically displayed in the signature of the supply function.
In this example, the help class is used to import the connection data of the corresponding airline carrier from the database table SPFLI to the internal table FLIGHTS.
Finally, the internal table is bound to the current context node CONNECTION_NODE. This allows you to display the appropriate values in the table Connections on the screen.

Each time the user selects another table element as the lead selection in the table Carrier, the value of the parameter PARENT_ELEMENT changes. The supply function of the context node CONNECTION_NODE is called and the values of its attributes are newly filled according to the selected table line in the table Carrier.

Note Supply functions can only access context data that

is contained in the corresponding parent node or
is contained in another node that is on a next-highest level compared to the node filled by the corresponding supply function.

Note If possible, avoid raising an exception in a supply function or in a method called by a supply function. Since supply function are often called during rendering, these exceptions cannot be processed sufficiently.

Note Supply functions are exclusively called by the runtime and therefore the time of their calls cannot be determined.

The supply function is also called if the content of the corresponding context node has been invalidated before. This should be thoroughly checked for each individual case due to performance reasons. From a technical point of view, each node of a context can be filled using a supply function. However, this is not always useful. Alternatives for the supply function are the method WDDOINIT and the event handler of the controller. For each context situation, the different time of the call and the call mechanisms of these methods need to be considered and only then decided which method to use. For further information on this subject, refer to chapter Filling the Context.