Globale Klassen mit Zugriff auf Screen

Re: Globale Klassen mit Zugriff auf Screen

ralf.wenzel hat geschrieben:

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.

Das Beispiel ist gut gewählt und du hast wieder in der Theorie völlig recht. Aber wir sind jetzt in der Realität und ich nehme jetzt mal ein Beispiel aus der Praxis. Das Feld mit der Werthilfe sei eine Materialnummer oder eine Kundennummer, weil diese beiden Felder üblicherweise einen Sack voll verschiedener Suchhilfen mit sich rumschleppen.
Die Lehre sagt: Modell stellt mir die Daten für die Suchhilfen zur Verfügung und der View muss das umsetzen. Und ja - das geht auch mit einem Dynpro - aber ich darf das zugehörige Feld dann aber nicht mehr auf das von SAP vorgehaltene Standarddatenelement referenzieren weil das ja automatisch die Suchhilfe und Doku mitbringt sondern ich muss die vorhandene Funktionalität ausschalten und mir die Daten vom Modell holen und das dann selber machen.
Die Praxis sagt: Nein - nimm das was da ist sofern das Modell nur das klassische SAP-Standardverhalten nachbildet.

Re: Globale Klassen mit Zugriff auf Screen

black_adept hat geschrieben:Die Lehre sagt: Modell stellt mir die Daten für die Suchhilfen zur Verfügung und der View muss das umsetzen. Und ja - das geht auch mit einem Dynpro - aber ich darf das zugehörige Feld dann aber nicht mehr auf das von SAP vorgehaltene Standarddatenelement referenzieren weil das ja automatisch die Suchhilfe und Doku mitbringt sondern ich muss die vorhandene Funktionalität ausschalten und mir die Daten vom Modell holen und das dann selber machen.
Die Praxis sagt: Nein - nimm das was da ist sofern das Modell nur das klassische SAP-Standardverhalten nachbildet.

Jein - "das geht AUCH mit einem Dynpro" ist genau die richtige Formulierung. Weil du das Konstrukt eh brauchst, wenn du dich nicht auf Dynpro-Technik festlegen willst. Genau das ist unser Anspruch bei der Entwicklung. Die Arbeit, die wir jetzt mehr reinstecken, sparen wir ein, wenn wir später alternative GUIs anbieten, weil dann alles schon da ist und man das nur noch aufrufen muss.

Und natürlich nimmt man nicht das Standarddatenelement, weil wir ja mit Klassenattributen in Dynpros arbeiten Da ist dann sowieso jeglicher Automatismus weg.

black_adept hat geschrieben:Aber das löst nicht das grundsätzliche Problem, dass SAP selber (noch) keine vernüftigen Tools dafür bereit stellt sondern weiterhin ausschließlich die angeblich aussterbende Dynpro-Methodik unterstüzt.
Denn nicht ihr solltet die MVC-Pflegetransaktionen schreiben sondern das sollte das System von sich aus anbieten. In Sonderfällen halte ich das Schreiben eines eigenen Dialogs ja für vertretbar - aber die Masse sollte vom System erledigt werden.

Jein, wir haben eine sehr komplexe Regelpflege, die mit einem normalen Viewcluster praktisch nicht pflegbar sind. Darum haben wir eine eigene Transaktion geschrieben (auch wieder alles generisch, so dass wir jede unserer Regelpflegen damit bedienen können). Das war der Hintergrund, warum wir etwas eigenes geschrieben haben.

Ich weiß nicht, wie das Customizing im S/4 aussieht, aber irgendwie muss man auch ein S/4 ja customizen können und ich kann mir nicht vorstellen, dass man das zwingend mit einer SAPGUI machen muss.

Zum Respekt: Der gebührt dem Entwicklungsleiter in unserem Team. Ich habe noch nie in einem so komplexen Projekt gearbeitet wie diesem und ich lerne unglaublich schnell unglaublich viel Neues dazu. Gerade in Sachen Abstraktion.


Ralf