Best Practices GWT Ereignisbehandlung

8

Ich habe eine Frage bezüglich der Ereignisbehandlung auf Client-Seite in GWT.

In unserer Anwendung haben wir eine recht komplexe Struktur verschiedener Module und Seiten, die über den gwt eventbus auf der Client-Seite kommunizieren. Jetzt ist die Menge der Ereignisse für meine Meinung zu schnell. Z.B. Ich öffne ein Popup, das ich brauche:

  1. Ein Ereignis zum Öffnen des Popups
  2. Ein Ereignis zum Abfragen einiger Daten im Client
  3. Ein Ereignis, um die Daten zurück zu erhalten und den Dialog
  4. zu füllen
  5. Ein Ereignis zum Schließen des Popups
  6. Ein Ereignis zum Behandeln der Speicherschaltfläche

Denke ich ein bisschen zu kompliziert oder fehlt etwas in der EventBus-Implementierung? Ich wollte nur etwas Feedback aus der Community haben, da Sie sich mit denselben Problemen konfrontiert sehen.

    
Gambo 20.09.2011, 11:32
quelle

1 Antwort

10

Für was es wert ist, habe ich viele Veranstaltungen und mehr wachsen. Und ja, ich frage mich, ob ich mit weniger umgehen kann, aber wenn ich ein Ereignis auslasse und Elemente direkt verlinke, bereue ich es.

Hier ist ein Beispiel, das ich gestern gerade repariert habe. Ich habe ein DataGrid-Widget. Ich unterstütze auch das Umordnen von Spalten, das Ausblenden von Spalten, das Ändern der Größe von Spalten und das Färben von Spalten mit einem Popup-Dialogfeld. Sie klicken auf eine Schaltfläche Konfigurieren, und ein Popup mit den aufgelisteten Spalten wird angezeigt, und der Benutzer kann auf Kontrollkästchen klicken, um Spalten ein- oder auszublenden, auf eine Schaltfläche Nach oben / Nach unten klicken, um Spalten neu zu sortieren und so weiter. Klicken Sie im Popup auf Übernehmen und das Popup verschwindet und das DataGrid wird neu konfiguriert.

Nur dass es nicht so war. Sie würden auf Anwenden klicken und das Popup würde nur dort sitzen, der Benutzer würde sich fragen, was vor sich ging, das DataGrid würde darunter neu konfigurieren, und dann würde das Popup verschwinden. Wir sprechen nur eine kurze Zeit - vielleicht eine Sekunde oder ein bisschen mehr - aber es war so auffällig. Warum ist es passiert? Weil ich faul wurde und das Popup direkt an die configure-Schaltfläche und die Apply-Schaltfläche direkt an das DataGrid band. Sie würden zum Beispiel auf Übernehmen klicken, und der Aufruf würde mit den neuen Konfigurationsinformationen an das DataGrid gesendet werden. Nur wenn der Anruf zurückkehrte, würde das Popup abgerissen werden.

Ich wusste, dass es schlecht war, als ich es tat, aber ich war faul. Also nahm ich die 20 Minuten, die ich benötigte, um zwei Nachrichten und zugehörige Handler in meinem Mediator Singleton zu schreiben. Eine Nachricht wird vom DataGrid ausgegeben, um den Konfigurationsdialog zu starten, und einer wird vom Popup zur Konfiguration des DataGrids ausgegeben. Jetzt sind die Widgets entkoppelt, und die Leistung ist viel schneller. Es gibt keinen Sinn für "Klebrigkeit".

Nun zu Ihrem Beispiel, können Sie nicht (1) und (2) kombinieren? Und auch (3), (4) und (5)? Wenn der Benutzer auf die Schaltfläche "Konfigurieren" in meiner App klickt, enthält das Ereignis die aktuellen Konfigurationsinformationen (einschließlich eines Verweises auf das DataGrid, von dem die Anforderung stammt). Sie können diese Information die "Nutzlast" nennen. Wenn der Benutzer im Popup auf die Schaltfläche Anwenden klickt, enthält die Ereignisnutzlast alle neuen Konfigurationsinformationen (einschließlich eines Verweises auf das ursprüngliche Ziel-DataGrid), die der Ereignishandler dem Ziel-DataGrid zuführt, wenn das Ereignis behandelt wird. Zwei Ereignisse - eines zum Starten der Konfiguration und eines zum Anwenden des Endergebnisses.

Ja, es gibt eine Fülle von Ereignissen in jeder App, die etwas Interessantes tun, aber Ereignisse können viele Informationen enthalten, also würde ich prüfen, ob Ihre Veranstaltungsorganisation zu zerrüttet ist.

Als zusätzliches Bit, hier ist der Code, den ich verwende. Ich habe Elemente dieses Musters schamlos aus einem von Googles Beispielen kopiert.

Der Benutzer kann mithilfe eines Menüelements Hilfe anfordern:

%Vor%

Für das Ereignis (in diesem Fall wurde das Ereignis ausgelöst, wenn der Benutzer auf den Menüpunkt "Hilfe" klickt):

%Vor%

Ich habe einen Singleton namens Mediator, in dem ALLE Ereignisse registriert sind:

%Vor%

Jedes Ereignis wird mit einem Command-Objekt verknüpft, um die Arbeit zu erledigen:

%Vor%

Alles ist entkoppelt. Das Menü-Widget ist an einen Befehl gebunden, der ausgeführt und dann abgeschlossen wird. Der Befehl löst das Ereignis auf dem Bus aus und wird dann abgeschlossen. Das Ereignis löst die Ausführung eines Befehls aus und der Vorgang wird abgeschlossen. Der Befehl zeigt die Popup-Hilfe an (in diesem Fall eine "nicht implementierte" Nachricht an den Benutzer - ja, ich komme bald dazu). Jede Interaktion mit einer Benutzereingabe wird extrem schnell bearbeitet und verrechnet. Es kann eine Reihe von Ereignissen auslösen, um eine lange Aktion auszuführen, ohne dabei die GUI zu binden. Und natürlich, da die Elemente entkoppelt sind, kann ich die gleichen Elemente an anderen Stellen aufrufen (zB den help-Befehl durch einen Knopfdruck sowie einen Menüeintrag aufrufen).

    
Steve J 20.09.2011, 13:45
quelle

Tags und Links