Navigation zwischen zwei Views 

Alle Views innerhalb eines Windows können über sogenannte Navigations-Links mit einander verbunden werden. Für den Benutzer bedeutet dies, dass beim Aufruf einer Web-Dynpro-Anwendung zunächst die als Startview gekennzeichnete View auf dem Bildschirm angezeigt wird. Durch Auslösen einer bestimmten Aktion (beispielsweise das Klicken auf eine Schaltfläche) kann dann eine Navigation ausgelöst werden mit der Folge, dass die bis dahin angezeigte View vom Bildschirm verschwindet und eine zweite View zur Anzeige gebracht wird.

Um eine Navigation zwischen zwei Views einrichten zu können muss für jede View ein sogenannter In-bzw. Outbound-Plug angelegt werden. Ein Plug stellt immer eine Verbindungsstelle dar über die eine View betreten bzw. verlassen werden kann.

Nähere Informationen zu Plugs und Navigations-Links finden Sie im Architekturhandbuch Web Dynpro. Das Anlegen und Pflegen von Plugs als Teil einer View ist im Werkzeughandbuch im Kapitel View: In- und Outbound-Plugs beschrieben, die Pflege von Navigations-Links dagegen ist Teil der Window-Struktur und findet daher im Layout des Windows statt.

Out- und Inbound-Plugs verfügen über unterschiedliche Eigenschaften:

Outbound-Plugs

Outbound-Plugs sind immer der Ausgangspunkt einer Navigation. Sie werden in einer beliebigen Methode des View-Controllers gerufen und zwar mit folgenden Aufruf:

 

WD_THIS->FIRE_MY_OUTBOUND_PLG(  ).

 

Das Attribut WD_THIS ist immer eine Selbstreferenz auf das Interface IF_<MY_VIEW> des View-Controllers. Für jeden Outbound-Plug, den Sie für diese View anlegen, wird dieses Interface um eine Methode FIRE_<MY_OUTBOUND_PLUG>_PLG erweitert.

 Legen Sie für die View View_1 die drei Outbound-Plugs OUT1, OUT2 und OUT3 an, werden im Interface IF_VIEW_1 die Methoden FIRE_OUT1_PLG, FIRE_OUT2_PLG und FIRE_OUT3_PLG erzeugt.

 

 Der Outbound-Plug selbst, und damit der Controller der View, enthalten keinerlei Information über das Ziel der angestoßenen Navigation. Die Verbindung zum ausgewählten Inbound-Plug einer folgenden View wird erst über einen Navigations-Link im Layout des Window eingerichtet. 

Übergabe von Parametern

Mit dem Methodenaufruf FIRE_<MY_OUTBOUND>_PLG kann ein Parameter übergeben werden. Dieser Parameter wird in die Parametertabelle auf der Registerkarte Outbound-Plugs eingetragen.

Für das unten angeführte Beispiel wurde der Methode FIRE_<MY_OUTBOUND>_PLG der Parameter editable hinzugefügt, welcher vom Typ WDY_BOOLEAN, also entweder ’X’ (wahr) oder ’’ (falsch) ist. Der Methodenaufruf wird daher entweder

 

WD_THIS->FIRE_MY_OUTBOUND_PLG( EDITABLE = 'X' ).

oder

WD_THIS->FIRE_MY_OUTBOUND_PLG( EDITABLE = '' ).

lauten.

Inbound-Plugs

Inbound-Plugs innerhalb eines Web-Dynpro-Windows werden immer direkt über einen Navigations-Link angesprochen, welcher, von einem Outbound-Plug ausgehend, eingerichtet worden ist (siehe Werkzeughandbuch, Kapitel Window: Layout). Mit dem Aufruf eines Inbound-Plugs ist der Aufruf einer eindeutig zugeordneten Ereignisbehandlermethode verbunden. Diese Methode wird mit Einrichten des Inbound-Plugs automatisch im Controller der View angelegt und auf der Registerkarte Methoden aufgelistet. Sie erhält den generierten Namen HANDLEMY_INBOUND_PLUG:

 Zu einem Inbound-Plug IN1 wird die Ereignisbehandlermethode HANDLEIN1 angelegt.

Diese Ereignisbehandlermethode ist leer und kann vom Anwendungsentwickler ausprogrammiert werden. Technisch unterscheidet sie sich nicht von anderen Ereignisbehandlermethoden des Controllers.

Auswertung von Parametern

Die Ereignisbehandlermethode eines Inbound-Plugs kann von der Methode FIRE_<MY_OUTBOUND>_PLG Werte von Parametern übernehmen. Der namensgleiche Parameter muss hierfür der Signatur der Ereignisbehandlermethode hinzugefügt werden.

 Übergibt ein Outbound-Plug den Parameter EDITABLE, so muss zum Auslesen des Parameters in der Signatur der Ereignisbehandlermethode des Inbound-Plugs der Parameter EDITABLE  hinzugefügt werden.

Der Wert des Parameters ist dann der Ereignisbehandlermethode bekannt und kann verwertet werden.

 Der Ereignisbehandler eines Inbound-Plugs wird unter anderem genutzt um Zustandsinformationen für die neue View zu aufzubereiten. Er sollte jedoch nicht dazu eingesetzt werden, Anwendungsdaten zu übergeben oder Anwendungs-Logik aufzurufen.

 

 Beispiel für eine Navigation mit Parameterübergabe

Im Ereignisbehandler einer Aktion einer ersten View wurde ein Outbound-Plug aufgerufen und der Parameter EDITABLE = ’X’ übergeben. Die über einen Navigations-Link angebundene Folge-View wird ein Element enthalten, dass aufgrund des übergebenen Wertes des Parameters EDITABLE dem Benutzer zur Änderung zur Verfügung stehen soll:

Aufruf des Outbound-Plugs OUT im Ereignisbehandler der ersten View

Zum Outbound-Plug OUT der View wurde, wie bereits oben erwähnt, der Parameter EDITABLE vom Dictionary-Typ WDY_BOOLEAN angelegt. Der Wert dieses Parameters wird zur Laufzeit mit der Methode übergeben:

 

WD_THIS->FIRE_OUT_PLG( EDITABLE = 'X' ).

 

Auswertung des Parameters im Ereignisbehandler HANDLEIN des Inbound-Plugs IN der zweiten View

Jedes UI-Element besitzt die Eigenschaft enabled, mit deren Hilfe die gesamte Funktionalität des Elements an- bzw. abgeschaltet werden kann. Ein Element, für das die Eigenschaft in seiner Eigenschaftentabelle im View-Designer nicht markiert ist, wird zwar auf dem Bildschirm dargestellt, jedoch können keinerlei Eingaben, Selektionen oder sonstige Interaktionen des Benutzers entgegengenommen werden, das UI-Element ist disabled. (Die Voreinstellung für diese Eigenschaft eines neu dem Layout hinzugefügten UI-Elements ist immer enabled). Der Anwendungsentwickler hat nun zwei Möglichkeiten, das Verhalten des UI-Elements zur Laufzeit zu steuern:

●     Die Eigenschaft enabled kann zur Designzeit über das Ankreuzfeld der Eigenschaftentabelle im View-Designer statisch festgelegt werden. Wann immer die zugehörige View dann aufgerufen wird, verhält sich dieses UI-Element gleich.

●     Die Eigenschaft enabled kann an einen Context-Knoten gebunden werden, welcher ein Attribut vom Typ WDY_BOOLEAN enthält. Der Wert dieses Attributs wird erst zur Laufzeit übergeben was dazu führt, dass das UI-Element je nach programmatischem Zusammenhang einmal mit voller Funktionalität zur Verfügung steht, ein anderes mal jedoch nur angezeigt wird.

In unserem Beispiel soll nun gerade der zweite Fall betrachtet werden:

Der Context der zweiten View beinhaltet neben Anwendungsdaten tragenden Context-Knoten auch einen Knoten zur Steuerung des Wertes der Eigenschaft enabled eines oder mehrerer UI-Elemente der View. Dieser Knoten soll den Namen STATUS tragen, er enthält genau ein Attribut ENABLED vom Typ WDY_BOOLEAN. Der Wert dieses Attributs wird nun von der Ereignisbehandlermethode HANDLEIN der zweiten View gesetzt:

 

method HANDLEIN .     data: L_CONTEXT_NODE type ref to IF_WD_CONTEXT_NODE.     L_CONTEXT_NODE = WD_CONTEXT->GET_CHILD_NODE( 'STATUS' ).   L_CONTEXT_NODE->SET_ATTRIBUTE( NAME = 'ENABLED' VALUE = EDITABLE ).   endmethod.

Da mit Hilfe des Übergabe-Parameters eine Eigenschaft eines Context-Knotens variiert werden soll, werden in der Ereignisbehandlermethode wieder Methoden des Interface IF_WD_CONTEX_NODE verwendet (siehe auch Kapitel Ereignisbehandler von Aktionen). In diesem Fall wird die Methode SET_ATTRIBUTE gerufen und das Attribut mit Namen ENABLED auf den Wert des Parameters EDITABLE gesetzt.

In Folge dieser Operation hat nun das Attribut ENABLED des Context-Knotens STATUS den Wert ’X’, so, wie er von der Methode WD_THIS->FIRE_OUT_PLG( EDITABLE = ’X’ ) der vorangegangenen View übergeben worden ist.

Resultat

Trägt das Attribut ENABLED den Wert ’X’ bedeutet dies, dass das oder die UI-Elemente, die ihre Eigenschaft enabled an das Attribut ENABLED gebunden haben, mit ihrer gesamten Funktionalität zu Verfügung stehen. In dem Moment, in dem die Methode FIRE_OUT_PLG den Wert ’ ’ übergibt, wird vom Ereignisbehandler des Inbound-Plugs der Folge-View auch das Attribut ENABLED auf den Wert ’ ’ gesetzt und das oder die UI-Elemente werden funktionslos auf dem Bildschirm dargestellt.