Event-Handling in Klasse auslagern
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo zusammen,
ich stehe grade mächtig auf dem Schlauch. Ich habe ein Programm mit folgender Struktur:
Das funktioniert auch alles. Nun sind diverse neue Anforderungen und Reports hinzugekommen, die es sinnvoll machen, die lokalen Klassen auszulagern in eigenständige Klassen, z.B. in ZCL_REPORT und ZCL_EVENTS.
In der Methode mach_irgendwas muss ich natürlich nur die lokale Klasse LCL_EVENTS gegen die neue Klasse ZCL_EVENTS ersetzen, aber in der Methode ON_DOUBLE_CLICK ist natürlich die Tabelle GT_TABELLE nicht mehr bekannt. Ich kann die Tabelle aber auch nicht übergeben, da die Im- und Exportparameter von ON_DOUBLE_CLICK nicht geändert werden können.
Wie setze ich das am besten um?
Viele Grüße
Margolwes
ich stehe grade mächtig auf dem Schlauch. Ich habe ein Programm mit folgender Struktur:
Code: Alles auswählen.
report report.
data: gt_tabelle type table of irgendwas.
class lcl_events definition.
public section.
class-methods: on_double_click for event double_click of cl_salv_events_table
importing row
column
sender.
endclass.
class lcl_report definition.
public section.
methods mach_irgendwas.
endclass
class lcl_events implementation.
method on_double_click.
[Tabelle gt_tabelle[ row ] auslesen]
endclass.
class lcl_report implementation.
method mach_irgendwas.
cl_salv_table=>factory( importing r_salv_table = lr_table changing t_table = gt_tabelle ).
set handler lcl_events=>on_double_click for lr_table->get_event( ).
lr_table->display( ).
[...]
endclass.
data: gcl_report type ref to lcl_report.
initialization.
gcl_report = new lcl_report( ).
start-of-selection.
gcl_report->mach_irgendwas( ).In der Methode mach_irgendwas muss ich natürlich nur die lokale Klasse LCL_EVENTS gegen die neue Klasse ZCL_EVENTS ersetzen, aber in der Methode ON_DOUBLE_CLICK ist natürlich die Tabelle GT_TABELLE nicht mehr bekannt. Ich kann die Tabelle aber auch nicht übergeben, da die Im- und Exportparameter von ON_DOUBLE_CLICK nicht geändert werden können.
Wie setze ich das am besten um?
Viele Grüße
Margolwes
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Indem du nur eine Klasse verwendest. Die Beispiele im ALV für den Event-Handler eine eigene Klasse zu machen stammen aus der Zeit, als man sonst noch kaum mit Klassen gearbeitet hat. Einfach die Methode ON_DOUBLE_CLICK in ZCL_REPORT implementieren und set handler entsprechend ändern. Dann hast du auch Zugriff auf die Daten.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Entweder du "vereinst" die beiden Klassen in eine oder du ziehst eine Schnittstelle zwischen den beiden ein.
z.B.: Eine Methode ZCL_REPORT=>SHOW_DETAIL die von ZCL_EVENTS im Ereignis ON_DOUBLE_CLICK aufgerufen wird. Natürlich müssen dann beide Klassen eine Instanz des jeweils anderen kennen um miteinander kommunizieren zu können.
Besser wäre meines Erachtens aber die Funktionsweisen anderes aufzuteilen und ein klassisches MVC Model aufzubauen. Da werden die Anzeige (Grid und Eventhandling), die Daten (Selektion und Speicherung) und die Verarbeitung (Modifikation und Businesslogik) von einander getrennt in Klassen implementiert.
z.B.: Eine Methode ZCL_REPORT=>SHOW_DETAIL die von ZCL_EVENTS im Ereignis ON_DOUBLE_CLICK aufgerufen wird. Natürlich müssen dann beide Klassen eine Instanz des jeweils anderen kennen um miteinander kommunizieren zu können.
Besser wäre meines Erachtens aber die Funktionsweisen anderes aufzuteilen und ein klassisches MVC Model aufzubauen. Da werden die Anzeige (Grid und Eventhandling), die Daten (Selektion und Speicherung) und die Verarbeitung (Modifikation und Businesslogik) von einander getrennt in Klassen implementiert.
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
Gibt es dafür irgendwo Beispiele?a-dead-trousers hat geschrieben: ↑08.05.2023 08:02Besser wäre meines Erachtens aber die Funktionsweisen anderes aufzuteilen und ein klassisches MVC Model aufzubauen. Da werden die Anzeige (Grid und Eventhandling), die Daten (Selektion und Speicherung) und die Verarbeitung (Modifikation und Businesslogik) von einander getrennt in Klassen implementiert.
Viele die ABAP OO nutzen, schreiben weiterhin nichts anderes als Funktionsbausteine. Dabei sind Design Pattern das A und O für wartbare Software
https://www.philipphauer.de/study/se/design-pattern.php
https://help.sap.com/doc/saphelp_nw74/7 ... cache=true
https://sapui5.hana.ondemand.com/sdk/#/ ... 91070.html
http://zevolving.com/category/abapobjec ... -patterns/
https://www.philipphauer.de/study/se/design-pattern.php
https://help.sap.com/doc/saphelp_nw74/7 ... cache=true
https://sapui5.hana.ondemand.com/sdk/#/ ... 91070.html
http://zevolving.com/category/abapobjec ... -patterns/
"Code lügt nicht ^^"
Die Aussage ist nicht korrekt. ZCL_EVENTS muss ZCL_REPORT kennen, aber nicht umgekehrt. ZCL_EVENTS arbeitet dann wie beim Command-Pattern und delegiert den Aufruf. Wenn hier mit statischen Methoden gearbeitet wird, was nur in Ausnahmefällen gemacht werden sollte ( aus Gründen wie Mocking für Test, Erweiterungen etc ), wird keine Instanz genutzt sondern nur der Aufruf delegiert an ZCL_Report.a-dead-trousers hat geschrieben: ↑08.05.2023 08:02
z.B.: Eine Methode ZCL_REPORT=>SHOW_DETAIL die von ZCL_EVENTS im Ereignis ON_DOUBLE_CLICK aufgerufen wird. Natürlich müssen dann beide Klassen eine Instanz des jeweils anderen kennen um miteinander kommunizieren zu können.
"Code lügt nicht ^^"
Btw. wenn ihr sowieso alles global machen wollt, braucht ihr auch keinen Report mehr. Das Starten des Programmes kann dann auch eine globale Klasse übernehmen. Sie braucht nur eine öffentliche Methode ( das kann auch eine Instanz-Methode sein ) auf die, die Transaktion gehangen wird. Sie darf dann nur im Konstruktor keine Pflichtparameter haben. Beim Aufruf der Transaktion erzeugt SAP automatisch eine Instanz dieser Klasse.
Die Aufgabe dieser Klasse ist nur den Code-Behind zu halten. Also z.b. weitere Objekte zu instanziieren.
Getreu dem Motto "Always program against an Interface"(APAAI) kannst du eine globale Klasse CL_EVENT_DOUBLECLICK machen. Diese delegiert die Informationen, die bei Doubleclick rein kommen dann an ein Interface und hat keine weitere Logik.
Damit wäre das Prinzip der Wiederverwendbarkeit erfüllt.
Wie funktioniert das ? Die Klasse Report mit dem Code-Behind erzeugt eine Instanz des ALV. Dafür müssen noch keine Daten bekannt sein, die kann man später setzen. Dann erzeugt sie eine Instanz der Klasse CL_EVENT_DOUBLECLICK und "invoked" z.b über den Konstructor, bei dieser eine Instanz der Klasse mit deiner Business-Logik. Diese Klasse hat das Interface an das die Doubleclick-klasse delegiert.
Dann registriert die Reportklasse die Eventklasse noch auf das ALV.
Jetzt hast du erreicht, das egal welche Businesslogik-Klasse dahinter liegt, das Prinzip immer gleich funktioniert und es keine Abhängigkeiten zwischen spezifischen Klassen gibt. Über Setter und Getter, statt über Konstruktor, wäre der "Befehlsempfänger" sogar zur Laufzeit austauschbar.
Wenn man es richtig macht und Soc beachtet, bräuchte man für alle Reports die nur die 1 Aufgabe haben ( Daten selektieren, aufbereiten und anzeigen ), nur eine Reportklasse. Die restliche Logik kann man in Klassen auslagern, die die dynamischen Teile dann laden.
Die Aufgabe dieser Klasse ist nur den Code-Behind zu halten. Also z.b. weitere Objekte zu instanziieren.
Getreu dem Motto "Always program against an Interface"(APAAI) kannst du eine globale Klasse CL_EVENT_DOUBLECLICK machen. Diese delegiert die Informationen, die bei Doubleclick rein kommen dann an ein Interface und hat keine weitere Logik.
Damit wäre das Prinzip der Wiederverwendbarkeit erfüllt.
Wie funktioniert das ? Die Klasse Report mit dem Code-Behind erzeugt eine Instanz des ALV. Dafür müssen noch keine Daten bekannt sein, die kann man später setzen. Dann erzeugt sie eine Instanz der Klasse CL_EVENT_DOUBLECLICK und "invoked" z.b über den Konstructor, bei dieser eine Instanz der Klasse mit deiner Business-Logik. Diese Klasse hat das Interface an das die Doubleclick-klasse delegiert.
Dann registriert die Reportklasse die Eventklasse noch auf das ALV.
Jetzt hast du erreicht, das egal welche Businesslogik-Klasse dahinter liegt, das Prinzip immer gleich funktioniert und es keine Abhängigkeiten zwischen spezifischen Klassen gibt. Über Setter und Getter, statt über Konstruktor, wäre der "Befehlsempfänger" sogar zur Laufzeit austauschbar.
Wenn man es richtig macht und Soc beachtet, bräuchte man für alle Reports die nur die 1 Aufgabe haben ( Daten selektieren, aufbereiten und anzeigen ), nur eine Reportklasse. Die restliche Logik kann man in Klassen auslagern, die die dynamischen Teile dann laden.
"Code lügt nicht ^^"
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2431
Views
Views
WebDynpro ALV Konfiguration in Assitance Klasse auslagern
von Trulchen » 16.09.2013 11:03 • Verfasst in Web-Dynpro, BSP + BHTML
von Trulchen » 16.09.2013 11:03 • Verfasst in Web-Dynpro, BSP + BHTML
2
Antw.
Antw.
1282
Views
Views
3
Antw.
Antw.
1573
Views
Views
2
Antw.
Antw.
2200
Views
Views
0
Antw.
Antw.
1441
Views
Views
WebDynpro: Event Handler für externes Event
von Tommy Nightmare » 20.06.2018 09:05 • Verfasst in ABAP Objects®
von Tommy Nightmare » 20.06.2018 09:05 • Verfasst in ABAP Objects®
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.