Customizing of Tabular Trees

Tabular widgets (with or without hierarchy) can be extended exclusively via a BAdI. This is done via the BAdI /PCH/CFW_BADI_LIST_TREE of the extension spot /PCH/CFW_WIDGET_LIST_TREE. The BAdI supports filters to restrict the implementation to a concrete application and/or a concrete widget.
In ProFramework there are basically two possibilities to implement a corresponding model:

• Using a structure for which a dynamic table is generated at runtime. The creation of the column catalog is primarily done automatically and the filling of the data can be done directly in the dynamically created table.

• Direct generation of nodes and items

In the BAdI interfaces, therefore, both the data table as standard table (often CT_DATA) and also the nodes and items (often CT_NODES and CT_ITEMS) are available at different places, whereby only one of both is in use and filled. However, the vast majority of models delivered by ProNovia are based on a data table. The following description refers exclusively to the use of a data table.

New Columns

If new columns are desired, then it must first be ensured that the data table is extended by new columns. Basically every model based on a data table must make its data structure known statically (see method STRUCTURE_NAME_DEFINE of the model to be extended). In principle it is possible to extend the data structure with further fields using the BAdI method STRUCTURE_EXTEND. However, there are isolated ProNovia models that do not support a subsequent extension of the structure by means of code, which manifests itself in a runtime error, since the new extended structure does not correspond to the statically defined data type. In such a case, an extension is only possible by directly adding new fields to the statically defined structure.

Changing Columns

The RETRIEVE_COLUMNS method can be used to change all columns. This includes visibility, order, label, width and other information related to sorting and filtering.

Fill data

The filling of the data takes place with different methods, since several times are intended for this. All methods have in common that the data table is passed with the parameter CT_DATA as standard table, the structure description with the parameter IO_DATA_DESC, the column definition with the parameter IT_COLUMNS and the requested columns with the parameter IT_REQUESTED_COLUMNS.
The structure description can ideally be used to create a dynamic row type. The use of the statically defined row type should be avoided, since this only works as long as no column extension is present. If it can be ensured by the customer that no column extension takes place, but only existing data is to be changed, the use of the static type is possible and simplifies the source code considerably.
During the implementation it is to be made certain in principle that the parameter IT_REQUESTED_COLUMNS is considered. Data are to be loaded only if this column was also requested, because thereby the performance can be improved.

Basically, the following methods are called at different times:

• LOAD
  When initially loading the data.

• LOAD_CHILDREN
  When expanding nodes that have not yet been loaded.

• LOAD_LAZY
  When reloading additional columns (e.g. when columns are shown or filters are applied to hidden columns).

• LOAD_LATE
  When loading new additional data (e.g. when new objects are created). The announcement of the data to be reloaded is done by the parameter CT_PARAMETERS. However, this parameter is very widget or model specific and cannot be described in general.

• NODE_REFRESH
  Is called if the data of a single node is to be updated.

In connection with the loading of the data additionally the method MAP_DATA_TO_TREE is available, which is called after each loading procedure and converts the data from the table into technical Nodes and Items. At this point, the display of the data can be directly influenced by changing specific individual items (e.g. the display style).