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
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
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
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
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
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
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
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
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
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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"
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"
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ja, ich geb dir recht. Schön ist was anderes.ralf.wenzel hat geschrieben:Dirty Assign als Standardverfahren zum Zugriff auf Dypros? Mit Verlaub: Hast du nen Stich? Das ist nichtmal als Scherz lustig.
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 Beschönigung 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.
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
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
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von Danny Winn (ForumUser / 10 / 3 /
0
)
»
Danke für den Hinweis.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.
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
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
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
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
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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
Oder sollte man ganz auf den Screenpainter verzichten und den Aufbau über Selection-Screens definieren?
Danny
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
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 )
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
hihi ist mir bisher nie aufgefallenralf.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
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
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.
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.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
Du wirst also entweder auf klassische Dynpros oder durchgängiges OO verzichten müssen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
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
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
Vergleichbare Themen
20
Antw.
Antw.
2791
Views
Views
Globale Klassen oder Lokale Klassen
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
8504
Views
Views
Anzeige einer Klasse und/oder Methode (Globale Klassen)
von hfahrian » 02.04.2018 07:33 • Verfasst in ABAP® Core
von hfahrian » 02.04.2018 07:33 • Verfasst in ABAP® Core
8
Antw.
Antw.
9138
Views
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
9
Antw.
Antw.
5483
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.