Globale Klassen mit Zugriff auf Screen

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

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD ist auch ein klassischer Fall, wie man OO schnell und billig faken kann. Ich habe da längst ein Eigenkonstrukt, das eine Datei als Objekt betrachtet. Das, was die SAP da liefert, ist kein OO, hätte an der Stelle aber welches werden können.


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

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


Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
ralf.wenzel hat geschrieben: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.
Wobei "nicht mehr lange" ein seeeeehr deeeeehnbarer Begriff ist... siehe SAP-Skript, das auch immer noch - meistens aus Performancegründen - verwendet wird.

Ich finde es äußerst schade und sehe keine Grund, warum man nicht Dynpros in und RFCs mit Klassen verwenden können sollte... Sehr ärgerlich.

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Du musst ja auch keine Mannjahre reinstecken, die Dynpros um OO zu erweitern. Hätte ich die Wahl, das zu machen oder nicht zu machen, würde ich es auch nicht tun wollen.


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 DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Sorry 4 resurrecting zombie thread, aber ich wäre dankbar, mal ein kleines Beispiel für ein in eine Funktionmsgruppe gekapseltes Dynpro zu sehen, das von einer Klasse über FBs gesteuert wird. Dynpros in FBs habe ich schon genutzt, aber wie man den Bogen zu den Klassen hinbekommt, ist mir noch nicht ganz klar.
Ralf hat geschrieben: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.
Totgesagte leben länger. Du hast das vor fast 2 Jahren geschrieben. Wenn man den Gerüchten hätte Glauben schenken dürfen, dann hätte es schon kein SAPGui 7.50 mehr gegeben. Und mittlerweile habe ich schon die erste Erwähnung von SAPGui 7.60 (nebst Kernel 775) in einem SAP-Hinweis gelesen. Ich denke, dass uns das gute SAPGui noch lange erhalten bleibt.

Hat auch erhebliche Vorteile. Browserbasiertes Arbeiten erzeugt viele zusätzliche Fehler- und Komplexitätsquellen. Manchmal ist es die Sache wert, in vielen Fällen aber eben auch nicht.

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
DeathAndPain hat geschrieben:Sorry 4 resurrecting zombie thread, aber ich wäre dankbar, mal ein kleines Beispiel für ein in eine Funktionmsgruppe gekapseltes Dynpro zu sehen, das von einer Klasse über FBs gesteuert wird. Dynpros in FBs habe ich schon genutzt, aber wie man den Bogen zu den Klassen hinbekommt, ist mir noch nicht ganz klar.
Grober Ablauf:
1) Klasse ruft zu Beginn einen INIT-Funktionsbaustein auf und übergibt eine Instanz von sich selbst an die Funktionsgruppe. Diese wird "global" (TOP-INLCUDE) gespeichert.
2) Dann, wenn ein Dynpro angezeigt werden soll, ruft die Klasse einen Funktionsbaustein ala SHOW_DYNPRO auf der intern das CALL SCREEN macht.
3) Die Klasse besitzt die Methoden PAI und PBO und diese werden in den jeweiligen Dynpro-Modulen der Funktionsgruppe mit der die in Schritt 1 übergebenen Instanz aufgerufen.

Wie man den Feldtransport zwischen Funktionsgruppe/Dynpro und Klasse steuert, da gibt es unterschiedliche Möglichkeiten:
1) In den PAI/PBO-Methoden als Parameter
2) Eigene Funktionsbausteine GET_DATA/SET_DATA
3) Im Dynpro als Feldname den (Public) Namen des Klassen- oder Objektattributs verweden.
4) Dirty Assign :evil:
5) uvm.
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 black_adept (Top Expert / 3943 / 105 / 886 ) »
Und verzichtest du dann auf die Dnypro-Logik-Elemente wie POV, POH, auf CHAIN-Anweisungen um bestimmte Blöcke eingabebereit zu halten, auf bedingte Modulaufrufe ( ON REQUEST, ON INPUT )?
Und verlagerst du die (automatischen) Wertprüfungen auch in die Klasse?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Diese Konstruktion mag einfach zu verstehen zu sein, wirkt aber auf mich etwas arg simpel. Also bei uns gibt es je OK-Code eine Handlermethode und der Dialog ist ein Beobachter der Applikation (im Sinne des Observer-Patterns). Das Auslösen eines OK-Codes feuert ein Event, das wirklich operativ das PAI ausführt. Dem kann man z. B. eine Schnittstelle übergeben, in der eine Methode eben die PAI-Logik enthält. Alle Dialoge und alle Applikationen erben von je einer Basisklasse.

Klingt kompliziert, ist es aber nur beim ersten Hinsehen. Und die wirklich konsequente Trennung von Dialog und Anwendung ist für viele noch sehr ungewohnt. Und auch wenn die SAPGUI noch weiter existiert (keiner weiß, wie lange - Wartungsende 2025), möchte ich meinem Kunden mehrere Möglichkeiten der GUI eröffnen, einfach weil das Stand der Technik ist, das zu tun.

So kapselt man so weit wie möglich und kann Abhängigkeiten sogar im Customizing pflegen, wenn man das will.


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 ) »
Auch an Ralf die exakte Frage von oben:
Und verzichtest du dann auf die Dnypro-Logik-Elemente wie POV, POH, auf CHAIN-Anweisungen um bestimmte Blöcke eingabebereit zu halten, auf bedingte Modulaufrufe ( ON REQUEST, ON INPUT )?
Und verlagerst du die (automatischen) Wertprüfungen auch in die Klasse?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Wertprüfungen mache ich in der Klasse. Schön generisch ;)

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 a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
black_adept hat geschrieben:Und verzichtest du dann auf die Dnypro-Logik-Elemente wie POV, POH, auf CHAIN-Anweisungen um bestimmte Blöcke eingabebereit zu halten, auf bedingte Modulaufrufe ( ON REQUEST, ON INPUT )?
Und verlagerst du die (automatischen) Wertprüfungen auch in die Klasse?
Wie gesagt: Stark vereinfacht.
Für POV/POH usw. kann man natürlich eigene Methoden implementieren die das abbilden.
Wie Ralf schon meinte kann man diesen Grundaufbau noch um beliebige andere Entwicklungspatterns erweitern. (Ich bin ja immer noch ein Fan von MVC :wink: )
Einzig eine adäquate CHAIN-Implementierung habe ich in den div. Dynpro-Klassen-Konzepten die mir über die Jahre so untergekommen sind, noch nie gesehen. Das mache ich bei meinen meist im PAI in einer großen CHECK-Methode oder ähnlichem.
Die CHAIN gliedern ja Felder zu Gruppen um sie in "einem Block" übertragen bzw. prüfen zu können, inklusive offen halten bei Fehlern. Bislang hätte ich das eigentlich so gut wie NIE gebraucht. Eine aussagekräftige Fehlermeldung im PAI reicht da oft schon aus um dasselbe zu bewirken. Vor allem das unterschiedliche Verhalten von MESSAGE in diesem Zusammenhang würde ich als Show-Stopper erachten. Wenn man in ABAP-OO, so wie Ralf immer predigt, eine Trennung zwischen Programmlogik und Oberfläche erreichen will, kann man kaum MESSAGE für Fehler- oder Warnmeldungen verwenden, sondern muss erst wieder eine Art von Nachrichtenklasse darüberstülpen. Wenn man dann bei der Ausgabe im SAPgui nicht aufpasst kann man sich mit einem falschen Meldungstyp zum falschen Verarbeitungszeitpunkt die ganze Programm- bzw. Dynproablauflogik zerstören.
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 ) »
Es ist ja noch viel schlimmer. Mit MESSAGE löse ich u. U. tief in der Geschäftslogik eine Bidschirmausgabe aus. Das zerstört jegliche Form von Kapselung von Grund auf.


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 ) »
@Ralf und a-d-t: Im Grunde stimme ich euch ja durchaus zu, was die Trennung von Geschäftslogik und Ausgabe angeht. Aber in meinen Augen geht ihr mit euren Ansätzen einfach einen Schritt zu weit um bloß möglichst dicht an der Theorie zu bleiben.
In der Theorie müsste das Model für jedes Feld des Views Methoden bereitstellen für
  • F1
  • F4
  • Prüfungen gegen Domäneninformationen wie erlaubte Werte, Konvertierungsexits, Groß/Kleinschreibung
  • Datenelementinformationen wie Label
  • Daten die sonst die SCREEN-Struktur bestimmt
  • bestimmt noch mehr Sachen
Ja, kann man alles machen . Aber will man das? Die Folge wäre doch bei sauberer Programmierung, dass ich mir eine "nackte" Kopie der Datenstrukturen erstelle um bloß keine automatischen Dynproaktionen zu erlauben sondern all das ans Model durchzureichen und dort dann all das nachzuprogrammieren, was SAP mit der "alten" Dynprounterstüztung von Haus aus kann.
Mir scheint das ein Overkill zu sein.
Mein bevorzugtes Vorgehen wäre eigentlicht etwas "gröber". Wir haben ein Businessobjekt welches die grundlegenden Aktionen und Validierungen bereitstellt ( z.b. BOPF ) und Controller und View vereinigen sich in einem Report um dort klassisch mit Dynpros die Daten darzustellen. Aber die Möglichkeiten des Dynpros zur Darstellung und Userinteraktion wie die o.a. Punkte würde ich voll im VC-Part ausreizen. Das Model hat zwar die Datenhoheit, aber wird von diversen Nebenschauplätzen entlastet.
Und wenn ich dann partout ein FIORI/SAPUI5 Anwendung haben will - dann generiert mit das Businessobjekt halt die ODATA-Schnittstelle und dort kann man dann mit einem anderen Controller und View dem User die Daten anbieten.
Die Frage ist doch auch - wann braucht man tatsächlich beides? Klassische GUI und FIORI, weil beide gleich gut bedienbar sind?

@Ralf als Totengräber des Dynpros: Hat SAP eigentlich schon mal so halbwegs was bereitgestellt wie einen UI5-Tabellenpflegegenerator mit wenistens ein paar von dessen Funktionalitäten? Denn wenn die Dynpros sterben muss doch eine Alternative her damit ich am Strand entspannt mit meinem iPhone Customizing ändern kann.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Du unterliegst einem Irrtum. Die Trennung dient nicht der Wahrung der reinen Lehre, sondern hat den Zweck, die Geschäftslogik zu kapseln. Weil es bei uns um eine Produktentwicklung geht, die unter jeder GUI funktionieren muss. Das geht nur durch Kapselung (wenn man nicht n-mal Geschäftslogik programmieren und testen und validieren und pflegen
will).

Mein MESSAGE-Beispiel ist da ganz gut: Natürlich ist es aufwendiger, darauf zu verzichten. Aber die Anweisung funktioniert halt nur in der SAPGUI, darum verbietet sie sich in der Geschäftslogik.


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 ) »
ralf.wenzel hat geschrieben:Mein MESSAGE-Beispiel ist da ganz gut: Natürlich ist es aufwendiger, darauf zu verzichten. Aber die Anweisung funktioniert halt nur in der SAPGUI, darum verbietet sie sich in der Geschäftslogik.
Das ist korrekt - aber wenn ich als View den Dynpro wähle habe ich dort eine SAPGUI und kann dort dann mit MESSAGE-Befehlen durchaus etwas erreichen.
Wie gesagt - das Model soll gerne die Datenhoheit haben um konsistent oder allgemeingültig zu sein. Aber da, wo der View mit SAP-Standardmitteln das erledigen kann, was das Model auch macht ( bzw. was im Model nachprogrammiert wird) spricht in meinen Augen nichts dagegen das dann auch im View zu machen ( Beispiel wie gesagt: F4, F1, Wertprüfungen ). Aber die reine Lehre sagt, dass ich das nicht darf.
ralf.wenzel hat geschrieben:Weil es bei uns um eine Produktentwicklung geht, die unter jeder GUI funktionieren muss. Das geht nur durch Kapselung (wenn man nicht n-mal Geschäftslogik programmieren und testen und validieren und pflegen will)
black_adept hat geschrieben:@Ralf als Totengräber des Dynpros: Hat SAP eigentlich schon mal so halbwegs was bereitgestellt wie einen UI5-Tabellenpflegegenerator mit wenistens ein paar von dessen Funktionalitäten? Denn wenn die Dynpros sterben muss doch eine Alternative her damit ich am Strand entspannt mit meinem iPhone Customizing ändern kann.
Ok - ich möchte bei einem Drink das Customizing eures Produkts ändern. Habt ihr alle Customizingtransaktionen so gekapselt wie oben von dir angesprochen oder "nur" das Produkt selber.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Globale Klassen mit Zugriff auf Screen

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
black_adept hat geschrieben:Das ist korrekt - aber wenn ich als View den Dynpro wähle habe ich dort eine SAPGUI und kann dort dann mit MESSAGE-Befehlen durchaus etwas erreichen.
WENN man das nur im View macht und nicht (wie wir) alle Meldungen protokollieren will (im BAL) kann man das machen, ja.
black_adept hat geschrieben:Aber die reine Lehre sagt, dass ich das nicht darf.
Weil es dafür gute Gründe gibt. Wenn ich eine Werthilfe verwende, ist die Aktion im Werthilfefenster Dialog, aber das Selektieren der Werte und das Auswählen eines Wertes lt. Benutzeraktion ist eben nicht dialogspezifisch. Weil du bei jeder Werthilfe die möglichen Werte selektieren (und zur Darstellung bereitstellen) musst.
black_adept hat geschrieben:Ok - ich möchte bei einem Drink das Customizing eures Produkts ändern. Habt ihr alle Customizingtransaktionen so gekapselt wie oben von dir angesprochen oder "nur" das Produkt selber.
Bei denen, die wir selbst geschrieben haben: Ja. In einigen Fällen behelfen wir uns mit dem Pflege-Generator. Das ist aber nur eine temporäre Lösung (wir können ohne Customizing nicht entwickeln ;) ). Aber das Ziel sind entsprechende Pflegetransaktionen nach MVC.


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

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 / 255

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 / 255

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