Globale Klassen mit Zugriff auf Screen

Re: Globale Klassen mit Zugriff auf Screen

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

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

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?

Re: Globale Klassen mit Zugriff auf Screen

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?

Re: Globale Klassen mit Zugriff auf Screen

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 )
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.

Re: Globale Klassen mit Zugriff auf Screen

@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.

Re: Globale Klassen mit Zugriff auf Screen

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.