Phasenmodell 

Einsatzmöglichkeiten

In diesem Abschnitt erhalten Sie Informationen über den Ablauf des Datentransports bei der Verarbeitung von Requests.

 

Hierbei ist der erste Request ausgenommen, da dort lediglich die Metadaten gelesen und die initiale Anzeige der Benutzungsoberfläche vorgenommen wird.

Zu bestimmten Zeitpunkten des Phasenmodells können Anwendungsentwickler Einfluss auf die Gestaltung der Oberflächen nehmen, wenn sie sie selbst dynamisch programmieren.

Ablauf

Im folgenden Bild ist der Verarbeitungsablauf beim Datentransport schematisch dargestellt.

Der Verarbeitungsablauf bei der Ereignisbehandlung ist detailliert im folgenden Bild dargestellt:

Datentransport vom Client zum Daten-Container

Daten, z.B. Benutzereingaben, werden vom Client in den Daten-Container transportiert. Der Daten-Container ist eine temporäre Datenablage. Die Daten sind zu diesem Zeitpunkt lediglich für die Laufzeitumgebung verfügbar, nicht jedoch für Anwendungsentwickler.

Validierung der Benutzereingabe

Sämtliche Benutzereingaben werden geprüft. Die Erkennung einer fehlerhafte Eingabe führt nicht zu einem Abbruch der Prüfung. Eine Blockierung des weiteren Datentransportes findet ebenfalls nicht statt. Fehlerhaft geprüfte Daten werden nicht in den Context transportiert.

Folgende Prüfungen/Konvertierungen werden durchgeführt:

●      typspezifische Prüfungen (z.B. keine Buchstaben in Datumsfeldern)

●      Benutzer-spezifische Konvertierungen (z.B. Datumsformat passend zu den Benutzereinstellungen)

●      Data-Dictionary-Prüfungen/Konvertierungen

○       Großbuchstaben-Konvertierung

○       Konvertierungs-Exits

○       Falls ein Context-Knoten mit Data-Dictionary-Bezug zu einem Währungsfeld auch das Referenzfeld enthält, wird dies berücksichtigt.

●      Check gegen die Wertemenge des Attributs

Für jede fehlerhafte Eingabe wird eine Fehlermeldung erzeugt, die nach dem Transport der Daten in den Controller-Context ausgegeben wird.

Datentransport vom Daten-Container in den Context

Von nun an sind die Daten für Anwendungsprogamme verfügbar.

WDDOAFTERACTION

Diese Methode wird für alle sichtbaren Views in dem Moment gerufen, in dem eine Aktion ausgeführt wird. Hier werden sinnvollerweise Funktionen untergebracht, die für alle zugehörigen Ereignisbehandler gleichermaßen erfolgen sollen. Auf diese Weise lässt sich unnötige Mehrfach-Programmierung in den Ereignisbehandlern vermeiden.

WDDOBEFOREACTION

Man kann in dieser Methode eigene Validierungen durchführen, bevor eine Aktion ausgelöst wird. Die Methode existiert nur für View-Controller. Sie wird für alle sichtbaren Views der Component durchlaufen, die der aktuellen Phasenmodell-Instanz zugeordnet ist. Dazu gehören auch alle eingebettenten Components.

Behandlung von Aktionen und Ereignissen

Dieser Schritt findet unabhängig vom Datentransport vom Daten-Container in den Context statt. Wenn bei der Validierung der Benutzereingaben eine fehlerhafte Eingabe erkannt wurde, wird nun eine entsprechende Fehlermeldung ausgeben und der Anwendungsentwickler hat die Möglichkeit, fehlerhafte Daten zu korrigieren.

Es gibt zwei grundsätzlich verschiedene Typen von Ereignisbehandlern (siehe  Detail-Grafik der Ereignisbehandlung):

●      Standard-Ereignisbehandler werden nur dann gerufen, wenn die Validierung keine Fehler in der Dateneingabe erkannt hat. Andernfalls, wenn also ein Fehler gefunden wurde, wird ein Ereignisbehandler dieses Typs unprozessiert übergangen und die Laufzeit springt direkt zum nächsten Schritt des Phasenmodells.

●      Validierungsunabhängige Ereignisbehandler werden immer aufgerufen, auch dann, wenn in der Validierung Fehler erkannt worden sind. Die in der Validierung erzeugten zugehörigen Fehlermeldungen werden in diesem Fall trotzdem ausgegeben.

Eine Navigation findet nur auf Veranlassung eines Ereignisbehandlers statt, d.h. ein Ereignisbehandler wird aufgerufen um anschließend eine Navigation anzustoßen.

WDDOBEFORENAVIGATION

In dieser Phase des Ablaufs kann mit Hilfe der Methode WDDOBEFORENAVIGATION eine zusätzliche Validierung von solchen Controller-Contexten stattfinden, die zwar im Rahmen der Anwendung gebraucht werden, die jedoch innerhalb dieses Request-Response-Ablaufs bislang nicht validiert wurden. Dies ist insbesondere bei komplexeren Web-Dynpro-Anwendungen wichtig. Die Methode existiert nur für den Component-Controller. Sie wird für die Component durchlaufen, die dieser Phasenmodell-Instanz zugeordnet ist sowie für alle eingebetteten Components.

Außerdem kann an dieser Stelle eine Navigation abgebrochen werden wenn bei der Ereignisbehandlung im vorherigen Schritt ein Fehler aufgetreten ist. Zum Abbruch einer Navigation kann die Methode CANCEL_NAVIGATIION im Interface IF_WD_COMPONENT aufgerufen werden. Der Aufruf dieser Methode unterbindet die Navigation für die gesamte Anwendung innerhalb eines Request-Response-Ablaufs. Navigations-Requests werden beim nächsten Durchlauf des Phasenmodells gelöscht und müssen neu initiiert werden.

Navigation und Initialisierung der Folge-View

Eine Navigation, die durch ein entsprechendes Ereignis angestoßen wurde, wird nun ausgeführt. Der Inbound-Plug der Folge-View wird gerufen und der zugehörige Ereignisbehandler wird prozessiert.

View-Modifizierung

Nachdem die Methode WDDOINIT der betreffenden View von der Laufzeit ausgeführt und die View entsprechend aufgebaut wurde, hat der Anwendungsentwickler nun die Möglichkeit, auf den UI-Tree einer View Einfluss zu nehmen, z.B. View-Elemente dynamisch hinzufügen.

Die Methode WDDOMODIFYVIEW wird für alle sichtbaren Views der dieser Phasenmodell-Instanz zugehörigen Component und den darin eingebetteten Components durchlaufen.

WDDOPOSTPROCESSING

Diese Methode wird als letzter Schritt vor dem Rendering gerufen. Sie ermöglicht daher das Einfügen anwendungsspezifischer Bereinigungsarbeiten.

Rendering

Beim Rendering wird die Darstellung der Benutzungsoberfläche auf dem Bildschirm vorgenommen, d.h. der Aufbau des UI-Trees sowie das Befüllen der Elemente aus dem Context.

 

Durch das Rendering werden sämtliche Daten der anzuzeigenden Views angefordert. Eventuell wird der zugehörige Context auch erst zu diesem Zeitpunkt befüllt. Hierzu werden die zugehörigen Supply-Funktionen aufgerufen. Im Rahmen der Anwendungsentwicklung sollte darauf geachtet werden, dass in Supply-Funktionen keine Ausnahmen ausgelöst werden.

Dialogfenster

Auch das Öffnen eines modalen Dialogfensters mit Web-Dynpro-Inhalt führt zur Erzeugung einer zusätzlichen Phasenmodell-Instanz. Dieses Öffnen eines internen Dialogfensters erfolgt asynchron, nach Ablauf der letzten Phase der Phasenmodell-Instanz des gerade aktiven Windows. Das Schließen eines internen Dialogfensters erfolgt ebenfalls asynchron, nach Ablauf der letzten Phase der Phasenmodell-Instanz des Dialogfensters. Danach wird das Phasenmodell des jetzt wieder aktiven Windows noch einmal durchlaufen.