Ansicht
Dokumentation

CL_PRP_BSP_C_ROLEAPPMOD_NEW - PLM Development Projects - BSP Controller Applikationskopf

CL_PRP_BSP_C_ROLEAPPMOD_NEW - PLM Development Projects - BSP Controller Applikationskopf

ROGBILLS - Synchronize billing plans   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Dieser Kontroller bildet zusammen mit der BSP-Seite roleAppointmentsMod.bsp eine UI-Komponente. Es können Termine für einen Geschäftspartner angelegt oder geändert werden. Zusätzlich können Termine versendet werden.

Die BSP-Seite wird komplett neu aufgebaut (Complete Modus) oder nur bei verändertem Inhalt (Differential Modus). Ob sich der Seiteninhalt geändert hat wird über das Attribut mv_changed gesteuert.

Die Komponente besizt 3 Modi (Attribut mv_mode):

READ: Schreibgeschützt, keine Änderungen sind möglich.

NEW: Neuanlagen können getätigt werden. Schreibmodus.

CHANGE: Änderungen und Neuanlagen können getätigt werden. Schreibmodus.

Methodendefinitionen DO_REQUEST (redefiniert)

Diese Methode ist für die Erzeugung und den Aufbau der BSP-View verantwortlich.

DO_HANDLE_EVENT (redefiniert)

Hier werden die Events die auf der zugehörigen View ausgelöst werden verarbeitert.

DO_FINISH_INPUT (redefiniert)

Hier wird dieser Controller vom Input - Processing abgemeldet, um nur dann die eingehenden Daten der BSP-Seite zu verarbeiten, wenn die Seite auch wirklich sichtbar ist

DO_HANDLE_DATA (redefiniert)

Die Felder der zugehörigen View werden zwischengespeichert.

GET_DATA

Läd Daten, die auf der Maske angezeigt werden.

Im Modus NEW wird das aktuelle Datum übernommen (UI-Kontroller roleAppointmentsNav) und der Start- und Endezeitpunkt der sichtbaren Zeitraums der Tagesansicht (UI-Komponente roleAppointmentsDetail).

Im Modus CHANGE werden die Attribute des Termins übernommen, welche übernommen wurde (UI-Komponente roleAppointmentsDetail) oder im aktuellen Kontroller neu angelegt wurde.

CHECK_ENTRIES

Überprüft die Daten der Maske, die voher über DO_HANDLE_DATA zwischengespeichert wurden. Datümer und Zeiten werden mit den Methoden GET_DATE bzw. GET_TIME überprüft und formatiert. Das Betrefffeld wird mit GET_SUBJECT überprüft.

DELETE_APPOINTMENT

Löscht einen Termin.

ON_APPOINTMENT_SELECTED (Ereignisbehadler)

Eine Termin wurde selektiert (UI-Komponente roleAppointmentsDetail). Dementsprechend wird die Komponente initialisiert und in den Modus CHANGE gesetzt.

GET_SUBJECT

Prüft, ob ein übergebener Betreffinhalt ein zulässigen Format hat. Ansonsten wird mit der Methode LAUNCH_MESSAGE eine Fehlermeldung ausgegeben.

GET_DATE

Prüft, ob ein übergebenes Datum ein zulässigen Format hat. Ansonsten wird mit der Methode LAUNCH_MESSAGE eine Fehlermeldung ausgegeben.

GET_TIME

Prüft, ob eine übergebene Zeit ein zulässigen Format hat. Ansonsten wird mit der Methode LAUNCH_MESSAGE eine Fehlermeldung ausgegeben.

MODIFY_APPOINTMENT

Hier wird je nachdem ob eine bestehende Assignement_GUID übergeben wird ein Termin angelegt oder geändert.

ON_BUPA_LINK_SELECTED (Ereignisbehadler)

Eine neuer Geschäftspartner wurde selektiert (UI-Komponente rolePersonAssign). Dementsprechend wird die Komponente initialisiert und in den Modus NEW gesetzt.

LAUNCH_MESSAGE

Eine Fehlermeldung wird erzeugt und ausgegeben.

Beziehungen

Beispiel

Hinweise

Weiterführende Informationen

Austausch geänderter Seiteninhalte

Der Mechanismus zum Austausch geänderter Seiteninhalte (im Dokument "Technical UI-Design" als "Differential rendering" bezeichnet) ist im Framework der Basis enthalten. Der Mechanismus wird in der Anwendung "Development Projects" als Erweiterung des Komponenten-Framework durch Anwendung folgender Regeln realisiert:

  • Das Layout jeder Komponente wird in ein div-Tag mit der ID der Komponente eingeschlossen (-> BSP View)
  • Der Controller der Komponente erhält ein Attribut "differential", das den Aufruf-Modus steuert
  • Der Controller muß über Änderungen seines eigenen Inhalts informiert sein
  • Der Controller macht Ausgaben vom Änderungs-Zustand und vom Aufruf-Modus abhängig:
  • Wurde der Controller im "complete"-Modus aufgerufen (differential ist initial), gibt der Controller seinen kompletten Inhalt aus und ruft eingebettete Komponenten ebenfalls im "complete"-Modus auf

  • Wurde der Controller im "differential"-Modus aufgerufen (differential = "X") und sein eigener Inhalt wurde seit dem letzten Request verändert, gibt der Controller seinen kompletten Inhalt aus und ruft eingebettete Komponenten im "complete"-Modus auf

  • Wurde der Controller im "differential"-Modus aufgerufen (differential = "X") und sein eigener Inhalt wurde seit dem letzten Request nicht verändert, gibt der Controller seinen eigenen Inhalt nicht aus und ruft eingebettete Komponenten im "differential"-Modus auf. Zusätzlich gibt der Controller außerhalb des die Komponente einschießenden div-Tag"s einen JavaScript-Block zum Ersetzen des Inhalts aus (CL_DPR_BSP_APPLICATION stellt dazu die Methode WRITE_REPLACE_SCRIPT zur Verfügung).

Eine Komponente, die den Austausch geänderter Seiteninhalte unterstützt kann jederzeit von einer anderen Komponente, die den Mechanismus nicht unterstützt, im "complete"-Mode (ist Default, wenn der Parameter "differential" nicht übergeben wird) aufgerufen werden.

Umgekehrt kann auch eine Komponente, die den Austausch geänderter Seiteninhalte nicht unterstützt, von einer Komponente, die den Mechanismus unterstützt, aufgerufen werden. Sofern die aufrufende Komponente über Änderungen der aufgerufenen Komponente nicht informiert ist, muß sie davon ausgehen, dass die aufgerufene Komponente geändert wurde. Letztendlich bedeutet das, dass sich die aufrufende Komponente dann immer so verhalten muß, als ob ihr eigener Inhalt verändert wurde und den kompletten Inhalt (ggf. mit Replace Script) ausgeben muß.






BAL_S_LOG - Application Log: Log header data   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7322 Date: 20240419 Time: 132117     sap01-206 ( 101 ms )