Globale Klassen mit Zugriff auf Screen

Globale Klassen mit Zugriff auf Screen

Hallo zusammen,

ich habe ein Paket mit globalen Klassen, einem Hauptprogramm und einem Screen via Screenpainter angelegt.

Nun möchte ich die Dynpros des Screens (aktuell Buttons, Textfelder, Table-Controls) über meine globalen Klassen (anstatt aus dem Hauptprogramm) ansprechen.

Ich könnte mir vorstellen, dass

1.) ... die Dynpros des Screens als Referenzparameter den Klassen- oder Objektmethoden übergeben werden (falls das möglich ist),
2.) ... die Dynpros in Includes statt im Hauptprogramm definiert werden und die Includes von den Klassen gezogen werden,
3.) ... es andere gemeinsame Ressourcen zwischen Klassen und dem Screen geben muss um den Zugriff zu gewähren,
4.) ... ich auf einem völlig falschen Weg bin.

Der zweite und dritte Vorschlag würde ein reines OO-Konzept zu einem hybriden Konzept ändern. Das wäre nicht sonderlich schön, jedoch evtl. unvermeidbar.

Was ist denn der übliche Weg um aus globalen Klassen auf Dynpro-Elemente eines Screens zuzugreifen?


Schöne Grüße
Danny

Re: Globale Klassen mit Zugriff auf Screen

Man könnte auch mit "dirty" assign arbeiten.
Oder mittels KLASSENNAME=>STATISCHES_ATTRIBUT als Feldnamen im Screenpainter zumindest den Feldtransport an eine Klasse anbinden. Leider funktionieren die PAI/PBO Module nur in Programmen/Funktionsgruppen. Da kann man das Coding aber auch auf ein Minimum beschränken und direkt eine statische Methode aufrufen.

Wenn man nicht mit statischen Klassen arbeiten möchten, funktioniert obriges auch mit Instanzattributen, aber dann muss man zumindest auf irgendeinem Weg die Instanzierung und die Bekanntmachung im Programm/der Funktionsgruppe bewerkstelligen. Was aber auch wieder mehr "prozeduralen" Code bedeutet.

Die statische Variante hat zusätzlich den Charme, dass es mehr dem Character eines Programms in SAP entspricht: Ein Programm kann auch nur einmal geladen (~ instanziert) werden, daher machte es auch nicht viel Sinn die das Dynpro steuernde Klasse (mehrfach-)instanzierbar zu machen.

Der Blog
https://blogs.sap.com/2005/09/08/oo-aba ... ogramming/
hat mich dazu veranlast selber ein OO-Dynpro-Framework zu erstellen. Das in dem Blog beschriebene war mir zu wenig umfangreich
POV/POH fehlt komplett. Um LOOP AT SCREEN muss man sich sowieso selbst kümmern. Dasselbe gilt für DYNPRO_READ_VALUES und VRM_SET_VALUES.

lg ADT

Re: Globale Klassen mit Zugriff auf Screen

ralf.wenzel hat geschrieben:Dirty Assign als Standardverfahren zum Zugriff auf Dypros? Mit Verlaub: Hast du nen Stich? Das ist nichtmal als Scherz lustig.

Ja, ich geb dir recht. Schön ist was anderes.
Zum Zugriff auf die Variablen im Programm, die für den Feldtransport benötigt werden, erschien es mir "damals" (vor 10 Jahren) als die flexibelste Variante. Ich wusste da noch nichts von der Möglichkeit mit KLASSE=>ATTRIBUT bzw. OBJEKT->ATTRIBUT als Feldnamen. Vielleicht wäre dann am Ende etwas ganz anderes rausgekommen. Die "dirty" assigns, die ich für das Auslesen der aktuellen Werte vom Trägerprogramm des Dynpros benutze, sind aber gut dokumentiert und beschränken sich auf eine zentrale Komponente meines Frameworks. Ich muss jedoch sagen, auch mit meinem derzeitigen Wissen, ist es für mich an dieser Stelle immer noch die flexibelste Lösung, um den Feldtransport von der Klasse zum Programm zu bewerkstelligen.

Glaub mir, ich versuche echt alles um "dirty" assigns so weit als möglich abzuwenden (auch mit MEMORY ID stehe ich auf Kriegsfuss) aber leider geht das in unserem SAP-Modul nicht immer. Der Standard ist hier teilweise schon so veraltet und die SAP-Partnerfirma traut sich da nur ganz behutsame Änderungen durchzuführen. Die neuen Sachen machen sie zwar auch schon in SAPUI und Co. aber die Abwärtskompatiblität muss trotzdem gegeben sein. Das Ding schaut für mich an einigen Stellen schon fast so aus wie ein Tumor aus dem viel schlimmere Geschwüre wachsen. Auf der anderen Seite steht mein Chef der es dem Kunden nach Möglichkeit immer auf Punkt und Komma recht machen will. Da muss man halt Kompromisse eingehen um den Standard ein wenig zu verbiegen *graus*.
Wenn du wirklich den Luxus hast, abseits von festgefahrenen Strukturen zu entwickeln, dann hast du meinen absoluten Respekt verdient.

Nur ein kleine Anekdote:
Ich glaub wir hatten in meinen "frühen" Tagen hier im Forum mal eine Diskussion zum Thema "veraltete" Befehlsstrukturen in SAP nicht mehr zu verwenden. Ich kam damals noch relativ frisch von der Java-Welt und mir graute vor den vielen Spaghetti-Code-Kontrukten ala DO-EXIT-ENDDO. Wenn ich mich nicht ganz täusche, warst du es der so vehement drauf pochte "wenn mir die Sprache die Möglichkeit dafür bietet warum soll ich sie dann nicht verwenden."
Das soll jetzt keine Be­schö­ni­gung für "dirty" assign sein, sondern nur ein kleiner Hinweis dafür, wie sehr sich Sichtweisen über die Jahre verändern können.

Sorry @Danny Winn, dass deine Frage hier ein wenig ins Off-Topic abgerutscht ist.

Re: Globale Klassen mit Zugriff auf Screen

ralf.wenzel hat geschrieben: Dynpros sind ein Uraltkonzept, sie können aus Klassen heraus nicht angesprochen werden. Dazu definiert man Funktionsgruppen, die Dynpros kapseln und die Kommunikation zu ihnen Mittels Funktionsbausteinen ermöglichen.

Danke für den Hinweis.
Dann möchte ich gerne auf alte Konzepte verzichten und eine moderne Alternative, die OO-kompatibel ist, verwenden.

Wie sieht die moderne Alternative denn aus?


Schöne Grüße
Danny

Re: Globale Klassen mit Zugriff auf Screen

Man muss nicht gleich auf SAPUI5 gehen (Webdynpro ist in meinen Augen tot, wenn es beim Kunden nicht schon benutzt wird), aber man sollte die Anwendung so aufbauen, dass man z. B. die UI einfach austauschen kann. Das meinte ich mit der Kapselung der Dynpros in Funktionsgruppen.

Ralf

Re: Globale Klassen mit Zugriff auf Screen

Hallo Danny,

wenn du auf Dynpros verzichten willst müsstest du dich theoretisch auch von dem ganzen Selektionsbildgeraffel trennen, da dort auch ein (Selektions)Dynpro erzeugt und verarbeitet wird.
Andererseits hat SAP hier schon eine gewisse Trennung von Code und Darstellung vorgenommen, so dass man hier auch anders argumentieren könnte.

Was dir Ralf aber letztlich sagen möchte ist, dass du das MVC-Designpattern berücksichtigen sollst - in deinem Fall ganz besonders halt der "V"-Part davon. Ob das "V" dann über Funktionsgruppen gekapselt wird ( die dann über die "V"-Klasse angesprochen werden ) oder ob du das Handling des V-Parts in deinem Programm sauber kapselst ist eigentlich egal. Funktionsgruppen haben den Vorteil, dass du gezwungen wirst sehr sauber zu arbeiten was die Datenübergaben angeht.

Was ich an deinem letzten Posting hingegen nicht verstehe ist der Hinweis auch Container und ALVs, wo du im 1. Posting doch von Buttons, Checkboxen geredet hast. ALVs kannst du auch ganz gut ohne (explizite) Dynpros verwenden. ( Hinweis wenn ich dein 1. Posting lese: Dynpro = Screen, die Dinger auf dem Dynpro wie Checkboxen, Buttons etc sind Dynproelemente )

Re: Globale Klassen mit Zugriff auf Screen

Mein Ziel war oder ist es innerhalb eines Paradigmas (hier: OO) zu bleiben anstatt ein hybrides Programmmodell zu implementieren, das zwischen mehreren Programmierparadigmen wechselt.
Komplett lässt sich das dem Anschein nach in ABAP nicht umsetzen. PBO und PAI sind nun mal von Natur aus Module, die der prozeduralen Programmieren und nicht der Objektorientierung zuzuordnen sind. Auch die Kapselung via Funktionsgruppen, respektive Funktionsbausteinen, entspricht keinem reinen OO, sondern es ist eine Hybridlösung, die formal betrachtet nur partiell OO-konform ist.

In diesem Bereich unterscheidet sich ABAP von anderen hybriden Sprachen wie Perl, Python und C++. Diese bieten de facto, ungeachtet deren ebenfalls hybriden Natur, die Eigenschaft Programme in reinem OO zu schreiben (mit Ausnahme des Einstiegspunktes aka main()-Funktion).

Was SAP mit ABAP-OO eingeführt hat, ist vom Prinzip her sehr mächtig und man hat an die formalen Kernfunktionen der Objektorientierung gedacht, u.a. Vererbung, Polymorphismus, Sichtbarkeit/Kapselung von Attributen und Methoden (private, protected, public), es gibt die Differenzierung zw. Klassenmembern und Objektmembern, das Interface-Konzept ist vorhanden und gut verwendbar, und neben den Standardkonstruktoren und Destruktoren hat die SAP sogar Klassen-Konstruktoren implementiert. Dies alles kann ich guten Gewissens loben.

Und weil mir ABAP-OO bereits mächtig und gut durchdacht erscheint, hätte ich mir ebenfalls gewünscht, dass es für alle klassischen/obsoleten Dynpro-Komponenten ein Upgrade in Form einer objektorienterten Dynpro-Version gibt. Teilweise ist das durchaus vorhanden. So verwende ich nun z.B. eine (abgeleitete) Klasse von CL_GUI_ALV_GRID zur Darstellung von Tabellen auf dem Screen und lasse das mal als objektorientierte Version des klassischen Table-Controls durchgehen. Es fehlt mir jedoch eine objektorientierte Version von anderen klassischen Dynpro-Elementen wie Checkboxen, Radio- und -Pushbuttons, von PBO und PAI, von Screens und Selection-Screens, etc.

Nun wird hier vermutlich so manch einer argumentieren wollen, dass ABAP ja recht alt ist und dass das alles historisch gewachsen ist, aber ich denke dieses Argument können wir heute mal beiseite lassen. Andere Sprachen wie C++ sind auch einst durch ANSI-C historisch gewachsen und bieten, wie zuvor bereits erwähnt, dennoch heutzutage die Möglichkeit reines OO zu programmieren.

Unter dem Strich schätze ich bin ich einfach ein nerdiger Typ, dem es gar nicht darum geht ein Problem programmatisch zu lösen, sondern ich hätte gerne eine rein objektorientierte Lösung eines Problems, was mir in der Programmiersprache ABAP, durch fehlende OO-Konstrukte erschwert wird. Zumindest ist dies mein subjektives Empfinden als ein Außenstehender, der von anderen Programmiersprachen zu ABAP gekommen ist.

Re: Globale Klassen mit Zugriff auf Screen

Hallo Danny Winn,

du bezeichnest die Kapselung von Dynpros in Funktionsgruppen, welche dann über Klassen aufgerufen werden könnten als Hybridlösung. Aber wenn du so vorgehst, müsstest du bei nahezu jeder Klasse erst mal nachschauen, ob die nicht im Coding auch noch irgendwo nicht-OO-Teile verwendet. Und da SAP ein recht lange gewachsenes Konstrukt ist, wirst du hier schon bei einfachen Sachen fündig werden. Nimm dir einfach mal die Methode CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD, die eigentlich nur einen FuBa aufruft und damit schon mal im Hybridbereich liegt, da hier nicht-OO-fähige Sachen gemacht werden dürfen.

Was die Verwendung des ALV-Grid als Table-Controlersatz angeht kann ich eigentlich nur mit dem Kopf schütteln .
Von einer rein formalen Betrachtungsweise verwendet ein ALV auch einen Dynpro. Nämlich den auf den er gebunden wird, womit du schon wieder dieses alte Relikt bekommst.
Und von einer rein praktischen Betrachtungsweise unterscheiden sich ALV und Table Control in ihrer Handhabung eklatant. Jeder hat seine Vor- und Nachteile.

Und letztlich - wenn du die klassischen Dynproelemente vermisst - lies doch mal ein wenig nach über Dynamic Documents. Ein Beispiel ist die SE80, wenn du den Repository-Browser aktiv hast, die beiden Eingabefelder zwischen den Buttons und der unteren Liste. Oder schau mal im Tricktresor zu diesem Thema nach - da kannst du schon sehr sehr Objektorientiert vorgehen