Globale Klassen mit Zugriff auf Screen

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
34 Beiträge • Seite 1 von 3 (current) Nächste
34 Beiträge Seite 1 von 3 (current) Nächste

Globale Klassen mit Zugriff auf Screen

Beitrag von Danny Winn (ForumUser / 10 / 3 / 0 ) »
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
4. stimmt.

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.


Ralf

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
Danny Winn

Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Man könnte auch mit "dirty" assign arbeiten. :evil:
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 :P
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
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Dirty Assign als Standardverfahren zum Zugriff auf Dypros? Mit Verlaub: Hast du nen Stich? Das ist nichtmal als Scherz lustig.

Leute wie ich fahren durchs Land um Programmierern beizubringen, wie professionelle Software-Entwicklung funktioniert und du kommst mit solchen Scherzen ums Eck, die ich dann bei Kunden rügen und rausprogrammieren muss. Derzeit mache ich Produktentwicklung in der Arzneimittelindustrie, die übrigens meine Lieblingsbranche ist (wegen des Validierungszwanges). Sprich: Keine Anwendung ohne definiertes Testverfahren, Dokumentationszwang, etc. Jede überflüssige Codezeile erzeugt Validierungsaufwand, was den Wiederverwendungsdruck erhöht.

Endlich mal nicht missionieren....

An den OP: Die Kapselung von Dialogen ist auch sinnvoll, weil das Ende der SAPGUI eingeläutet ist. Ich erinnere mich an einen Ex-Kunden, der weder SAPUI5 noch S/HANA einführen kann, weil er alles monolithisch programmiert hat und mal locker 50 Mannjahre Entwicklung in die Tonne wirft, weil ALLES neugeschrieben und (was viel schlimmer ist) neu getestet werden muss. Du bist IT-Fachkraft, du solltest auf einem Niveau arbeiten, auf das du mit ein bisschen Stolz blicken kannst.


Ralf, Standardspruch: "jeder Schokoriegel der bei F....o vom Band läuft ist besser und professioneller getestet als Ihre geschäftskritische Software"
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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. :up:

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. :wink:

Sorry @Danny Winn, dass deine Frage hier ein wenig ins Off-Topic abgerutscht ist.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Das muss sehr lange her sein, dass ich sowas geschrieben habe und dann habe ich mich deutlich weiterentwickelt. Ich bin heute ein Wadenbeißer, was sauberes Coding angeht.

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von Danny Winn (ForumUser / 10 / 3 / 0 ) »
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

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Webdynpro, SAPUI und Co.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von Danny Winn (ForumUser / 10 / 3 / 0 ) »
Ich würde dann auf dem Screenpainter einen Container anlegen, dort programmatisch einen ALV integrieren, die Steuerung über Funktionsgruppen.

Oder sollte man ganz auf den Screenpainter verzichten und den Aufbau über Selection-Screens definieren?


Danny

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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 )

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ralf.wenzel

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von hausi (ForumUser / 56 / 11 / 1 ) »
ralf.wenzel hat geschrieben:Das muss sehr lange her sein, dass ich sowas geschrieben habe und dann habe ich mich deutlich weiterentwickelt. Ich bin heute ein Wadenbeißer, was sauberes Coding angeht.

Ralf
hihi ist mir bisher nie aufgefallen :D :D

Nein ich find das soweit ja auch gut - man will ja was lernen... man kann vllt. nicht immer den Idealfall nutzen - sollte aber verstehen warum wie etwas funktioniert :evil:

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von Danny Winn (ForumUser / 10 / 3 / 0 ) »
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

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Der Punkt ist, dass kein Mensch bei der SAP Zeit und Geld investieren wollte, um Dynpros OO-fähig zu machen, weil ohnehin klar war, dass die klassische SAPGUI nicht mehr lange lebt.

Du wirst also entweder auf klassische Dynpros oder durchgängiges OO verzichten müssen.

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Vergleichbare Themen

20
Antw.
973
Views
Globale Klassen oder Lokale Klassen
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
3
Antw.
6860
Views
Anzeige einer Klasse und/oder Methode (Globale Klassen)
von hfahrian » 02.04.2018 07:33 • Verfasst in ABAP® Core
8
Antw.
8179
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
9
Antw.
4612
Views
Lokale Klassen in globalen Klassen
von ralf.wenzel » 20.04.2020 22:55 • Verfasst in ABAP Objects®
1
Antw.
1541
Views
Globale Variable
von wummy » 14.03.2007 13:48 • Verfasst in ABAP® Core

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140