Tabellarische Widgets (mit oder ohne Hierachie) können ausschliesslich über ein BAdI erweitert werden. Dies erfolgt über das BAdI /PCH/CFW_BADI_LIST_TREE des Erweiterungsspots /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.
- Im Zusammenhang mit dem Laden der Daten steht zusätzlich die Methode MAP_DATA_TO_TREE zu Verfügung, die nach jedem Ladevorgang aufgerufen wird und die Daten aus der Tabelle in technische Nodes und Items umwandelt. An dieser Stelle kann direkt auf die Darstellung der Daten Einfluss genommen werden, indem spezifische einzelne Items verändert werden (z.B. der Anzeigestil).