ABAP OO und Tabstip mittels Wizard

Re: ABAP OO und Tabstip mittels Wizard

hi!

Kurze Antwort: ABAP OO funktioniert nicht mit Dynpros.
Lange Antwort: Du musst das Dynpro zwar in einen Programm ablegen, kannst aber von ABAP OO aus die Steuerung machen.
Hier ist ein guter Ansatz wie das funktionieren könnte.
Ich hab den als Vorlage genommen und selbst ein Framework geschrieben, dass als Brücke zwischen ABAP OO und Dynpro dient.
Dabei bin ich auf folgenden (genialen) trick gestoßen:
Nenn eine Variable im Dynpro z.B. ZCL_DYNPRO_TEST=>ICON. Dann leg eine Klasse ZCL_DYNPRO_TEST an und platziere darin ein statisches Attribut mit dem Namen ICON. Testweise kannst du im CLASS-CONSTURCTOR dem Attribut einen Wert zuweisen.
Das Dynpro normal aufrufen und anschauen was passiert.
Dasselbe funktioniert übrigens auch mit Instanzen: LR_DYNPRO->ICON

Jetzt zu deinem TabStrip-Dilemma:
Du musst auf alle Fälle im Wizzard die Variante mit "Steuerung am Appl.Server" auswählen. Dann erhälltst du ein Dynpro auf dem nur ein SubScreen-Bereich für den TabStrip angelegt wird. Den Inhalt der PBO/PAI-Module die der Wizzard produziert, kannst du auschneiden und in entsprechende Methoden deiner Klasse verfrachten. Die Control-Variable muss im Programm bleiben. Auf die kannst du von der Klasse aus mittels dem ASSIGN-Trick zugreifen. Das ist insofern wichtig, alsdass hiermit die Verarbeitung des Tabstrips gesteuert wird und die Definition nur in einem Programm erfolgen darf.
Von den PAI/PBO-Module rufst du jetzt die entsprechenden Methoden deiner Klasse auf.
Die SubScreen-Anweisung in deinem Dynpro versorgst du nicht über Programmvariablen sondern über den oben erwähnten Trick mit statischen Attributen.
Im Programm musst du nur noch eine FORM-Routine platzieren die das CALL SCREEN des Hauptdynpros übernimmt.

Ich würde empfehlen die Verbindung zwischen Dynpro/Programm und Klasse über statische Attribute/Methoden zu realisieren. Es ist zwar möglich das auch über Instanzen zu machen, aber dazu muss gewährleistet sein, dass das Programm vor dem Aufruf des Dynpros mit der richtigen Instanz versorgt wird. Daher brauchst du eine zusätzliche Funktion/Form die das übernimmt. Wohingegen bei einer statischen Übergabe dieser Schritt entfällt. Du kannst ja trotzdem Problemlos von der Instanz auf die statischen Attribute zugreifen.

Auch entsprechen statische Attribute/Methoden eher der Verwendung von Variablen bei der Dynpro-Verarbeitung.
Ich hab nämlich bei meinen Rechercen herausgefunden, dass man ein und dasselbe Dynpro mittels der SubScreen-Technick mehrfach verwenden kann. Es werden immer die aktuell in der Variable gespeicherten Werte an das Dynpro übertragen bzw von dort ausgelesen.
Auf diesem Umstand fußt mein OO-Dynpro-Framework. Um eine Mehrfachverwendung von Dynpros zu gewährleisten und um nicht jedesmal die PAI/PBO Verarbeitung neu zu schreiben, hab ich nur EINE einzige Dynproklasse und belasse die Variablen im Programm zum Dynpro. Der Zugriff erfolgt über ASSIGN und welche Variablen im Dynpro benötigt werden lesen ich über IMPORT DYNPRO aus.
Von dieser Klasse ausgehend leite ich dann je Anwendung weitere Klassen ab die die spezifische Abarbeitung der Dynpros implementieren.
Quasi das "V" in MVC
Die Hauptklasse ist inzwischen so umfangreich, dass ich DROPDOWN, F1/F4 (mit vollständigem PAI/PBO via DYNP_VALUES_READ/DYNP_VALUES_UPDATE), LOOP AT SCREEN usw. soweit zentralisiert habe und ich darauf keine Rücksicht mehr zu nehmen brauche. Es werden immer die gleichen Steps durchlaufen.
Sogar der LIST-PROCESSOR und SELECTION-SCREENS (mit Modifikation des GUI-Status) sind mit dabei

lg ADT