Tabellarische Widgets (mit oder ohne Hierachie) können ausschliesslich über ein BAdI erweitert werden. Dies erfolgt über das Tabular widgets (with or without hierarchy) can be extended exclusively via a BAdI. This is done via the BAdI /PCH/CFW_BADI_LIST_TREE des Erweiterungsspots of the extension spot /PCH/CFW_WIDGET_LIST_TREE. Das BAdI unterstützt Filter, um die Implementierung auf eine konkrete Anwendung und/oder ein konkretes Widget einzuschränken.
Im ProFramework bestehen grundsätzlich zwei Möglichkeiten um ein entsprechendes Model zu implementieren:
- Verwendung einer Struktur, für die zur Laufzeit eine dynamische Tabelle erzeugt wird. Das Erzeugen vom Spaltenkatalog erfolgt primär automatisch und das Abfüllen der Daten kann direkt in der dynamisch erzeugten Tabelle erfolgen.
- Direktes Erzeugen von Nodes und Items
In den BAdI Schnittstellen stehen deshalb an verschiedenen Stellen sowohl die Datentabelle als Standardtabelle (oftmals CT_DATA) und auch die Nodes und Items (oftmals CT_NODES und CT_ITEMS) zu Verfügung, wobei nur jeweils eines von beidem in Verwendung und gefüllt ist. Die allermeisten von ProNovia ausglieferten Modelle basieren allerdings auf einer Datentabelle. Die nachfolgende Beschreibung bezieht sich ausschliesslich auf die Verwendung einer Datentabelle.
Neue Spalten
Sind neue Spalten gewünscht, dann muss zuerst sichergestellt werden, dass die Datentabelle um neue Spalten erweitert werden. Grundsätzlich muss jedes auf einer Datentabelle basierendes Model seine Datenstruktur statisch bekannt machen (Siehe Methode STRUCTURE_NAME_DEFINE des zu erweiterten Models). Grundsätzlich ist es möglich mit der BAdI-Methode STRUCTURE_EXTEND die Datenstruktur um weitere Felder zu erweitern. Allerdings existieren vereinzelte ProNovia Modelle, die eine nachträgliche Erweiterung der Struktur mittels Code nicht unterstützen, was sich in einem Laufzeitfehler äussert, da die neue erweiterte Struktur nicht dem statisch definierten Datentyp entspricht. In einem solchen Fall ist eine Erweiterung nur möglich, indem direkt die statisch definierte Struktur um neue Felder erweitert wird.
Spalten ändern
Mit der Methode RETRIEVE_COLUMNS können sämtliche Spalten geändert werden. Dies umfasst die Sichbarkeit, die Reihenfolge, die Bezeichnung, die Breite und weitere Informationen im Zusammenhang mit der Sortierung und Filterung.
Daten füllen
Das Befüllen der Daten erfolgt mit verschiedenen Methoden, da hierzu mehrere Zeitpunkte vorgesehen sind. Allen Methoden ist gleich, dass die Datentabelle über den Parameter CT_DATA als Standardtabelle, die Strukturbeschreibung mit dem Parameter IO_DATA_DESC, die Spaltendefinition mit dem Parameter IT_COLUMNS und die angeforderten Spalten mit dem Parameter IT_REQUESTED_COLUMNS übergeben wird.
Die Strukturbeschreibung kann idealerweise dazu verwendet werden, um einen dynamischen Zeilentyp zu erzeugen. Die Verwendung des statisch definierten Zeilentyps ist zu vermeiden, da dies nur solange funktioniert, wie keine Spaltenerweiterung vorhanden ist. Kann kundenseitig sichergestellt werden, dass keine Erweiterung der Spalten stattfindet, sondern nur bestehende Daten geändert werden sollen, ist die Verwendung der statischen Typs möglich und vereinfacht den Quellcode erheblich.
Bei der Implementierung ist grundsätzlich darauf zu achten, dass der Parameter IT_REQUESTED_COLUMNS berücksichtigt wird. Daten sind nur zu laden, wenn diese Spalte auch angefordert wurde, weil damit die Performance verbessert werden kann.
Grundsätzlich werden die folgenden Methoden zu unterschiedlichen Zeitpunkten aufgerufen:
- LOAD Beim initialen Laden der Daten.
- LOAD_CHILDREN Beim expandieren von noch nicht geladenen Knoten.
- LOAD_LAZY Beim Nachladen von zusätzlichen Spalten (z.B. wenn Spalten eingeblendet oder Filter auf ausgeblendeten Spalten angewendet werden)
- LOAD_LATE Beim Laden von neuen zusätzlichen Daten (z.B. wenn neue Objekte erzeugt werden). Die Bekanntgabe der nachzuladenden Daten erfolgt über den Parameter CT_PARAMETERS. Allerdings ist dieser Parameter sehr Widget bzw. Model-spezifisch und kann nicht allgemein beschrieben werden.
- NODE_REFRESH Wird aufgerufen, wenn die Daten eines einzelnen Knoten aktualisiert werden sollen.
Wenn mit der Erweiterung ausschliesslich zusätzliche Daten gefüllt oder bestehende Daten geändert, nicht aber die Ladelogik (z.B. von Kindern) geändert werden soll, wird sinnvollerweise die gesamte Datenbeschaffungslogik in eine separate Methode ausgelagert, die in allen oben beschriebenen Methoden aufgerufen wird und ausschliesslich die Daten anreichert.
...
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.
| Info |
|---|
If only additional data is to be filled or existing data is to be changed with the enhancement, but not the loading logic (e.g. of children), it makes sense to outsource the entire data retrieval logic to a separate method, which is called in all methods described above and only enriches the data. |
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).