Supply-Funktion 

Jedem Context-Knoten eines Controllers kann eine Supply-Funktion zugeordnet werden. Diese Supply-Funktion wird von der Laufzeit immer dann aufgerufen, wenn die Daten des Context-Knotens gebraucht werden. Dies ist zum Beispiel immer dann der Fall, wenn ein UI-Element zum ersten Mal mit den Daten des zugehörigen Contexts angezeigt werden soll.

Grundsätzlich wird die Supply-Funktion immer dann aufgerufen wenn auf ein oder mehrere Elemente eines Context-Knotens zugegriffen wird und

●      der Context-Knoten bisher nicht gefüllt oder initial ist, oder

●      der Context-Knoten in einem vorangegangenen Schritt invalidiert wurde.

Supply-Funktionen von Singleton-Knoten

Der Einsatz einer Supply-Funktion ist besonders sinnvoll im Zusammenhang mit Singleton-Knoten: Die Werte der Elemente eines Unterknotens vom Typ Singleton hängen ab von dem Element des Eltern-Knotens, das zu diesem Zeitpunkt die Lead-Selection trägt. Wenn die Lead-Selection durch den Benutzer geändert wird, kann die Supply-Funktion auf das neue Lead-Selection-Element zugreifen und die Werte der Unterknoten-Elemente entsprechend neu berechnen. Sie finden Informationen zum Konzept von Singleton- und Multiple-Context-Knoten im Architekturhandbuch zu Web Dynpro im Kapitel Context-Knoten: Eigenschaften.

Der Einsatz der Supply-Funktion eines Singleton-Knotens lässt sich am einfachsten anhand eines Beispiels erläutern.

 Beispiel: Elementbasierte Detail-Anzeige

In einer View soll in einer Tabelle mit Namen Carrier eine Liste aller verfügbaren Fluggesellschaften dargestellt werden. Das UI-Element vom Typ Tabelle wird dazu an einen Context-Knoten gebunden, welcher mit Hilfe einer geeigneten Methode innerhalb der Methode WDDOINIT des View-Controllers gefüllt wird. Die Methode WDDOINIT wird beim ersten Aufruf der Anwendung aufgerufen sodass die Daten für die Tabellenelemente zum Zeitpunkt der ersten Anzeige auf dem Bildschirm für den Benutzer sichtbar sind.

Eine zweite Tabelle (Connections) soll, in Abhängigkeit vom ausgewählten Element der ersten Tabelle, alle Flüge anzeigen, die für die jeweilige Fluggesellschaft angeboten werden. Der Benutzer soll also in der ersten Tabelle nach einander verschiedene Zeilen auswählen können um in der zweiten Tabelle jeweils zugehörige Detail-Information zu finden. Dafür muss die zweite Tabelle in Abhängigkeit von der ausgewählten Fluggesellschaft neu gefüllt werden ohne dass die View als Ganzes neu aufgebaut werden muss.     

Der Context dieser View ist nun wie folgt aufgebaut:

Die erste Tabelle (Carrier) ist an den Context-Knoten CARRIER_NODE gebunden, die Tabelle Connections an den Context-Knoten CONNECTION_NODE. Als Ergebnis eines ersten Aufrufs der Anwendung enthält der obere Knoten auf Grund der Programmierung der Methode WDDOINIT des View-Controllers alle Elemente der Datenbank-Tabelle SCARR und damit eine Liste aller Fluggesellschaften, deren IDs sowie die URL der jeweiligen Homepage. Die Lead-Selection des Context-Knotens wurde automatisch auf das erste Element des Knotens gelegt, damit ist die an erster Stelle in der Tabelle stehende Fluggesellschaft als Lead-Selection-Element ausgezeichnet:

 

In der Tabelle Connections werden alle Flüge aufgelistet, die für die durch die Lead-Selection ausgezeichnete Fluggesellschaft zur Verfügung stehen. Der Context-Knoten CONNECTION_NODE, an den diese zweite Tabelle gebunden ist, wird über seine Supply-Funktion GET_CONNECTIONS aus der Datenbank-Tabelle SPFLI versorgt. Dabei wird das Lead-Selection-Element der Carrier-Tabelle ausgelesen und alle Verbindungsinformationen zu der betreffenden Fluggesellschaft angezeigt:

 

Wird in der Tabelle Carrier durch Mausklick die Lead-Selection auf ein anderes Tabellenelement gelegt,

 

ändert sich automatisch der Inhalt der Tabelle Connections:

 

 

Die Supply-Funktion des Context-Knotens CONNECTION_NODE

Zur Realisierung einer solchen View muss in der Supply-Funktion der Knotens CONNECTION_NODE das Lead-Selection-Element des Knotens CARRIER_NODE ausgelesen werden:

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.

●      Zunächst wird eine interne Variable vom Typ eines Context-Elements des Eltern-Knotens CARRIER_NODE sowie eine zweite interne Variable vom Dictionary-Typ SPFLI_TAB deklariert.

●      Anschließend werden die Wertes der Attribute des Lead-Selection-Elements des Eltern-Knotens CARRIER_NODE an die interne Variable CARR_ATTR übergeben.

 Jede Supply-Funktion kennt hierfür den Parameter PARENT_ELEMENT vom Bezugstyp IF_WD_CONTEXT_ELEMENT.

PARENT_ELEMENT ist eine Referenz auf genau das Lead-Selection-Element des zum aktuellen Knoten gehörenden Eltern-Knoten. Der Parameter wird automatisch in der Signatur der Supply-Funktion angezeigt.

●      Unter Verwendung einer Helferklasse werden in diesem Beispiel dann die zur jeweiligen Fluggesellschaft passenden Verbindungsdaten aus der Datenbank-Tabelle SPFLI in die interne Tabelle FLIGHTS eingelesen.

●      Zuletzt wird diese interne Tabelle an den aktuelle Context-Knoten CONNECTION_NODE gebunden. Damit können dann die passenden Werte in der Tabelle Connections am Bildschirm zur Anzeige gebracht werden.

Jedes Mal wenn ein Benutzer die Lead-Selection in der Tabelle Carrier auf eine andere Tabellenzeile legt, ändert sich der Wert des Parameters PARENT_ELEMENT. Die Supply-Funktion des Context-Knotens CONNECTION_NODE wird aufgerufen und die Werte seiner Attribute werden unter Berücksichtigung der ausgewählten Tabellenzeile der Tabelle Carrier neu gefüllt.

 Supply-Funktionen dürfen nur auf solche Context-Daten zugreifen, die entweder

○        im zugehörigen Vater-Knoten liegen oder

○        in einem anderen Knoten, der in der Hierarchie direkt oberhalb desjenigen Knotens liegt, der über die betreffende Supply-Funktion versorgt wird. 

 In einer Supply-Funktion oder in einer von einer Supply-Funktion aufgerufenen Methode sollte nach Möglichkeit keine Exception ausgelöst werden. Da Supply-Funktionen oft erst zum Zeitpunkt des Renderings gerufen werden, können solche Exceptions nicht mehr ausreichend bearbeitet werden.

 

 Da Supply-Funktionen ausschließlich von der Laufzeit gerufen werden, dürfen keine Annahmen bezüglich des Zeitpunkts ihres Aufrufs getroffen werden.

Die Supply-Funktion wird auch dann aufgerufen, wenn der Inhalt des betreffenden Context-Knotens vorher invalidiert wurde. Dies sollte aus Performance-Gründen jedoch in jedem Einzelfall genau geprüft werden. Jeder Knoten eines Contextes kann technisch mit Hilfe seiner Supply-Funktion gefüllt werden. Dies ist jedoch nicht immer sinnvoll. Alternativen zur Supply-Funktion sind die Methode WDDOINIT oder ein Eventhandler des Controllers. Da sich diese Methoden durch Aufrufzeitpunkt und Aufrufmechanismus voneinander unterscheiden, sollte für jede Context-Situation die Entscheidung für die eine oder andere Methode abgewogen werden. Weitere Informationen zu diesem Thema finden Sie im Kapitel Das Füllen des Contexts.

Die Supply-Funktion von gemappten Contexten

Supply-Funktionen werden grundsätzlich nur für ungemappte Context-Knoten aufgerufen. Wenn Sie also beispielsweise den Context-Knoten eines View-Contextes auf den Context-Knoten eines Component-Controller-Contextes gemappt haben, so wird nur die Supply-Funktion des Component-Controller-Contextes tatsächlich aufgerufen. Auch wenn die Supply-Funktion des View-Context-Knotens validen Quelltext enthält, wird dieser nicht ausgeführt, da der Context-Knoten kein Originalknoten ist.