Anfang des Inhaltsbereichs

Prozessdokumentation Verarbeitungsablauf  Dokument im Navigationsbaum lokalisieren

Einsatzmöglichkeiten

Die Methoden der Klasse Klasse CL_BSP_CONTROLLER2 werden bei der Erstellung von Komponenten im Rahmen des Model-View-Controller Design Pattern eingesetzt.

Hinweis

Bei jedem Request wird die ganze Hierarchie-Tiefe abgearbeitet.
Die Hierarchie selbst wird bei der Ausgabe definiert.

Ablauf

  1. Zuerst wird DO_INIT aufgerufen.
  2. Danach wird DO_INITATTRIBUTES aufgerufen.
  3. Dann wird DO_REQUEST aufgerufen.

DO_REQUEST kümmert sich bei einem Haupt-Controller sowohl um die Eingabe- als auch um die Ausgabeverarbeitung.
    1. Eingabeverarbeitung

Der Request vom Browser geht direkt an den obersten Controller. Dieser dispatcht die Eingaben an die jeweiligen Sub-Controller. Dafür steht die Service-Funktion DISPATCH_INPUT zur Verfügung.

DISPATCH_INPUT liest die Form-Felder aus dem Request und dispatcht sie an den passenden Sub-Controller. Die Form-Felder sind mit einem Präfix versehen.

Hinweis

Das Schreiben der Präfixe wird für BSP-Elemente, z.B. von der BSP-Extension HTMLB, automatisch durchgeführt.
Wenn es sich dagegen um reines HTML handelt bzw. um HTML-Tags, dann müssen Sie Ihre Eingabedaten explizit mit dem Namen des Controllers als Präfix versehen. Für das Versehen mit Präfixen steht für diesen Fall die Service-Funktion GET_ID zur Verfügung.

Alle Daten, die nicht zu einer der Unter-Komponenten gehören, müssen über die Methode DISPATCH_INPUT im Haupt-Controller verarbeitet werden. Daher werden die folgenden Methoden (s.u.) aufgerufen:

Diese drei Methoden werden vom Parent-Controller nur mit den Form-Feldern für den aktuellen Controller aufgerufen.
    1. Ausgabeverarbeitung

Die Festlegung der Ausgabeverarbeitung beinhaltet das Ausgeben der nächsten Seite. Ein View wird erzeugt und ausgegeben. Abhängig vom Zustand des obersten Controllers könnnen Sie auch einen Sub-Controller auf inaktiv setzen oder neue Controller erzeugen.

Der Verarbeitungsablauf bei der Ausgabe wird in der folgenden Abbildung schematisch dargestellt:

Page Output

Diese Grafik wird im zugehörigen Text erklärt

Im einzelnen erfüllt DO_REQUEST bei der Ausgabe die folgenden Aufgaben:
      1. DO_REQUEST stellt fest, ob Daten vom Modell oder von den globalen Attributen geholt werden müssen
      2. DO_REQUEST holt die Tabelle mit den Objektschlüsseln vom obersten Controller ab.
      3. DO_REQUEST erzeugt einen View.
      4. DO_REQUEST setzt die richtigen Attribute für den View.
      5. DO_REQUEST ruft den View auf.

Behandeln von Events

Wenn eine Komponente Events beinhaltet, dann ruft DISPATCH_INPUT den HTMLB-Manager auf. Der HTMLB-Manager sammelt die relevanten Informationen, u.a. die ID, also die ID des Objekts, das den jeweiligen Event ausgelöst hat.

Als nächstes ruft DISPATCH_INPUT die Methode DO_HANDLE_DATA auf. DO_HANDLE_DATA wird von allen Controllern (d.h. für alle aktiven Komponenten) aufgerufen, also sowohl vom obersten Controller als auch von allen Sub-Controllern. Mit DO_HANDLE_DATA wird die Modellklasse (siehe auch Datenbindung) gefüllt: Form-Felder und Nachrichten für das globale messages-Objekt (s.u.) werden übergeben.

Hinweis

Wenn Ihre Modellklasse auf CL_BSP_MODEL basiert und Sie Ihre Setter- und Getter-Methoden entsprechend definiert haben, dann werden die Form-Felder automatisch gefüllt.

Der Verarbeitungsablauf bei DO_HANDLE_DATA wird in der folgenden Abbildung schematisch dargestellt:

Page Input (DO_HANDLE_DATA)

Diese Grafik wird im zugehörigen Text erklärt

Nachdem DO_HANDLE_DATA alle Daten gefüllt hat, wird die Methode DO_HANDLE_EVENT für den einen Controller aufgerufen, der für den Eingabe-Event zuständig ist. Dabei wird die ID des Events mitgegeben und der Event wird an den Controller dispatcht. DO_HANDLE_EVENT gibt auch den Parameter GLOBAL_EVENT (einen String) aus. Wenn es sich um einen HTMLB-Event handelt, wird das dazugehörige Objekt HTMLB_EVENT gefüllt.

Hinweis

Das Dispatchen von Events an den zuständigen Controller funktioniert nur dann, wenn an dem dazugehörigen HTMLB-Element die Element-ID vergeben wurde (Attribut id).

DO_HANDLE_EVENT hat auch Zugriff auf das globale messages-Objekt und kann bei Bedarf weitere Schritte unternehmen, z.B. kann diese Methode veranlassen, dass im Fehlerfall die Daten erneut zur Anzeige gebracht werden.

Der Verarbeitungsablauf bei DO_HANDLE_EVENT wird in der folgenden Abbildung schematisch dargestellt:

Page Input (DO_HANDLE_EVENT)

Diese Grafik wird im zugehörigen Text erklärt

Hinweis

Beachten Sie, dass hier nur ein Unter-Controller aufgerufen wird.

Schließlich wird immer (für jeden Controller, d.h. für alle aktiven Komponenten) die Methode DO_FINISH_INPUT aufgerufen. Hiermit können Sie auf Ereignisse, die in einer Komponente passieren, in einer anderen Komponente reagieren. Hierfür verwenden Sie den Parameter GLOBAL_EVENT, der in der Methode DO_HANDLE_EVENT gesetzt wurde. Durch diesen globalen Event soll am Ende der Eingabeverarbeitung jede Komponente genau wissen, welche Events es gibt und wie darauf reagiert wird.

Der Verarbeitungsablauf bei DO_FINISH_INPUT wird in der folgenden Abbildung schematisch dargestellt:

Page Input (DO_FINISH_INPUT)

Diese Grafik wird im zugehörigen Text erklärt

Globale Meldungen

Der Parameter GLOBAL_MESSAGES wird von allen Komponenten geteilt. Diesen Parameter verwenden Sie für die Behandlung von fehlerhaften Benutzereingaben, z.B. um ganz allgemein auszugeben, dass ein Fehler aufgetreten ist, oder dass bei einer Benutzereingabe das Ende-Datum vor dem Anfangs-Datum liegt, etc.

Der Haupt-Controller erzeugt die globalen Meldungen und reicht sie weiter an alle Unter-Controller. Das bekannte messages-Objekt dagegen ist lokal. Wenn nun in einem Controller das lokale messages-Objekt gefüllt ist, dann können sie diese Information an das globale messages-Objekt weiterreichen und in einer beliebigen Komponente darauf reagieren.

Controller und ihre IDs

Üblicherweise gibt es einen Haupt-Controller, einen obersten View, sowie diverse Sub-Controller und weitere Views.

Ein Haupt-Controller ruft zuerst CREATE_VIEW, dann SET_ATTRIBUTE für den View und danach CALL_VIEW. Der obersten Controller kann auch Unter-Controller erzeugen. Dies geschieht über das <bsp:call>-Element, dem als Attribute die PAGE und die COMP_ID mitgegeben werden. Zusätzlich können über das eingebettete Element <bsp:parameter> Parameter für Name und Wert mitgegeben werden.

Diese Grafik wird im zugehörigen Text erklärt

Die Attributübergabe geschieht entweder im View oder über den obersten Controller.

Hinweis

Der Controller wird immer über die COMPONENT_ID erkannt. Die COMPONENT_ID hält eine Referenz auf den betreffenden Controller.
In der Methode CREATE_CONTROLLER ist diese Referenz der Parameter COMPONENT_ID und im <bsp:call>-Element ist dies das Attribut COMP_ID.
Beim Anlegen eines Controllers wird eine Referenz an den Parent-Controller übergeben, der somit eine Liste aller zu ihm gehörender Sub-Controller besitzt. Jeder Sub-Controller kann seinen Parent-Controller nach der COMP_ID jedes weiteren Sub-Controllers befragen.

 

 

 Ende des Inhaltsbereichs