Eventhandler „intern“ oder „extern“?

Eventhandler „intern“ oder „extern“?

Moin.

Gegeben sei als Beispiel ein SALV-Grid, das für die Toolbar einen Eventhandler braucht.

Entwickler 1 schreibt dazu eine globale Klasse mit den entsprechenden Ereignisbehandler-Methoden. Dazu baut er ein Interface, das alle möglichen Methodendefinitionen enthält.

Entwickler 2 pappt die Methoden an die ALV-Klasse selbst, indem er das Interface an die Klasse hängt, die den ALV aufbaut.

Entwickler 2 sagt „Ist einfacher, muss ich nix suchen“

Entwickler 1 sagt: “Hassu noch alle Latten am Zaun???“

Welchen der beiden Wege würdet ihr gehen und warum? Ich sage extra (noch) nicht, was meine Antwort wäre, um den Verlauf der Diskussion nicht zu beeinflussen.


Ralf *lernt aus solchen Diskussionen immer wahnsinnig viel!

Re: Eventhandler „intern“ oder „extern“?

Da die Events des SALV in einem Interface gekappselt sind wäre mein erster Reflex Variante 1 zu machen. Es macht nämlich durchaus Sinn die Eventhandler "austauschbar" aufzubauen um so die Trennung von Oberfläche (SALV) und Verarbeitung (Handler) im Sinne eines MVC-Models zu gewährleisten.
Und jetzt kommt das ABER.
Die SALV wie auch die ALV-Klassen sind sehr stark auf den SAPgui zugeschnitten. Ein Austausch der Logik macht meines Erachtens dadurch nur bedingt Sinn. Solange die SAP kein Interface bereitstellt mit dem man z.B. unaghängig davon ob man sich im WD oder im SAPgui bewegt, dieselben Events mitbekommt, wiegt für mich das Argument der "Nähe" zum Coding von Entwickler 2 mehr. Lieber bau ich mir da eine eigene Klasse die das eigentliche "Eventhandling" (oder besser Controlling) macht und von der Viewklasse mit einer einheitlichen Schnittstelle aufgerufen werden kann. Die Viewklasse selbst kann dann entweder ein WD, SALV oder was auch immer sein, inklusive der echten klassenspezifischen Event-Handler.
Und das Argument, dass man durch eine eigene Event-Handler Klasse Code, den man immer wieder braucht vereinheitlichen und austauschbar gestalten kann, möchte ich gleich wiedersprechen, als dass ich nur sehr selten in diesen Genuss gekommen bin. Meist hab ich mir *gedacht* das könnte ich wiederverwenden und habs dann beim nächsten Projekt doch nicht geschafft es zu integrieren weil die Kundenanforderung doch die eine oder andere Spezialität beinhaltet hat, die es wieder unmöglich gemacht hat.

Re: Eventhandler „intern“ oder „extern“?

Ich mache es meistens wie Entwickler 1, sofern ich im betreffenden Report nur 1-2 SALVs habe. Bei komplexem Monitoring mit vielen SALVs tendiere ich eher zur Methode des Entwicklers 2, um eine passende hierarchische Übersicht im SE80-Treeview zu erhalten.

Re: Eventhandler „intern“ oder „extern“?

Moin Ralf,

für einfache Reports lege ich seltenst Klassen im DDIC ab um das Eventhandling zu steuern sondern mache das in programmlokalen Klassen. Und irgendwelche Interfaces baue ich da eigentlich nie ein.
Wenn ich das mal auf Reports runterbreche: Wenn das Progrämmchen hinreichend kurz ist: Alles in eine Klasse. Wenn es etwas komplexer wird werden mehrere (immer noch programmlokale) Klassen angelegt - und da könnten die Eventhandler mal in die eine mal die andere Klasse rutschen, je nachdem wie ich in dem Report gruppiere.

Für allgemeine Toolklassen, die wiederverwendet werden können ( ich schätze das meintest du`? ) und diesen SALV irgendwie gekapselt anbieten würde ich es nach Entwickler2 handhaben, da dann alles zusammen liegt was zusammen gehört. Aber irgendwelche Interfaces würde ich hier auch nicht einbauen - mir erschließt sich gerade nicht wozu die gut sein sollen bei der allgemeinen Problemstellung.

Re: Eventhandler „intern“ oder „extern“?

Ich bin ein Freund von in sich autarken Klassen. Wenn ich also einen ALV baue, schreibe ich eine Klasse, die den SALV als Attribut* enthält und den Eventhandler, so dass ich diesen SALV in jedes Control einbauen kann, ohne etwas ändern zu müssen, wobei die Klasse derart parametrisierbar sein muss, dass in Control A die Toolbar dargestellt wird, in Control B aber bestimmte Buttons nicht. Hierfür benutze ich den Subscribe-Mechanismus, den ich hier schon mehrfach beschrieben habe (Button meldet sich an Toolbar an und implementiert ein „Button-Interface“, in dem die Funktion codiert ist, die er ausführen soll).

Das widerspricht keinesfalls obigem Konzept, denn auch die Button-Klasse ist in sich autark und könnte so auch woanders eingesetzt werden.

Insofern habe ich auch keine Scheu, die notwendige spezifische Datenbeschaffung aus dem SALV heraus aufzurufen.


Ralf

*vereinfachte Darstellung, in Wahrheit handelt es sich um ein Interface, hinter dem sich auch ein ALV verstecken könnte, an dem Punkt arbeite ich gerade