Wicket und komplexe Ajax-Szenarien

Question

Wenn ein Bildschirm mehrere interagierende Ajax-Steuerelemente hat und Sie die Sichtbarkeit von Komponenten steuern wollen, um auf diese Steuerelemente zu reagieren (so dass Sie nur das anzeigen, was in einer bestimmten Situation sinnvoll ist), rufen Sie target.addComponent() manuell für alles, was Sie aktualisieren wollen, ist mühsam und nicht sehr wartungsfreundlich.

Schließlich wird das Netz der onClick y onUpdate Rückrufe können einen Punkt erreichen, an dem das Hinzufügen einer neuen Komponente auf dem Bildschirm viel schwieriger wird, als es eigentlich sein sollte.

Welche gängigen Strategien (oder sogar Bibliotheken, falls es so etwas gibt) gibt es, um diesen Aufbau von Komplexität zu vermeiden?

Aktualisierung: Vielen Dank für Ihre Antworten, ich fand sie alle sehr nützlich, aber ich kann nur eine davon akzeptieren. Entschuldigung.

Answer 1

In Wicket 1.5 gibt es einen Ereignisbus. Jede Komponente hat eine onEvent(Object payload) Methode. Mit component.send() können Sie Ereignisse senden und jede Komponente kann die Nutzlast (z.B. UserJoinedEvent Objekt) überprüfen und entscheiden, ob sie an der aktuellen Ajax-Antwort teilnehmen möchte. Siehe http://www.wicket-library.com/wicket-examples/events/ für eine einfache Demonstration.

Answer 2

Sie könnten strukturelle Komponenten hinzufügen, wie z. B. WebMarkupContainer s, wenn Sie diese zum AjaxTarget hinzufügen, wird alles, was darin enthalten ist, ebenfalls aktualisiert. So können Sie Gruppen von Komponenten in einer einzigen Zeile aktualisieren.

Answer 3

Wenn ich Komponenten für eine Seite erstelle, neige ich dazu, sie zu Komponentenarrays hinzuzufügen:

Component[] pageComponents = {
                  new TextField<String>("Field1"),
                  new TextField<String>("Field2"),
                  new TextField<String>("Field3")
}

Ab Wicket 1.5 nehmen die Add-Funktionen Array-Parameter [1]. Daher können Elemente wie folgt zur Seite oder zum Ziel hinzugefügt werden:

add(pageComponents);
target.add(pageComponents);

Die Komponenten können dann in Gruppen zusammengefasst werden, je nachdem, welche Sie gemeinsam aktualisieren möchten.

[1] http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket/1.5-M3/wicket-1.5-M3-javadoc.jar!/org/apache/wicket/ajax/AjaxRequestTarget.html

Answer 4

Von wie vielen Komponenten sprechen wir denn hier? Von zehn? Zwanzig? Hunderten?

Für bis zu zwanzig oder mehr können Sie einen Zustandsregler haben, der steuert, welche Komponenten angezeigt werden sollen. Dieser Controller setzt das sichtbare Feld eines Komponentenmodells und Sie fügen immer alle Komponenten zu Ihren Anfragen hinzu, die von dem Controller behandelt werden. Die Ajax-Ereignisse der Komponenten leiten Sie einfach an die Handle-Methode des Controllers weiter.

Für eine wirklich große Anzahl von Komponenten, die eine zu große Nutzlast für eine gute Leistung haben, könnten Sie Javascript-Bibliotheken wie jQuery verwenden, um das Anzeigen und Ausblenden von Dingen durch den Client zu tun.

Answer 5

Ich verwende derzeit eine Art modifiziertes Observer-Pattern, um einen Event-Bus in Wicket 1.4 zu simulieren.

Meine Seiten fungieren als beobachtbarer Beobachter, da sich meine Komponenten nicht kennen und in verschiedenen Kombinationen auf mehreren Seiten wiederverwendet werden. Immer wenn eine Komponente ein Ajax-Ereignis empfängt, das sich auch auf andere Komponenten auswirken könnte, ruft sie eine Methode auf ihrer Seite mit einem Event-Objekt und dem Ajax-Ziel auf. Die Seite ruft eine ähnliche Methode auf allen Komponenten auf, die sich für diese Art von Ereignissen registriert haben, und jede Komponente kann auf der Grundlage des übergebenen Event-Objekts entscheiden, ob und wie sie reagieren muss und sich mit dem Ziel verbinden kann.

Das Gleiche kann mit Hilfe des Wicket-Besuchers archiviert werden. Ich weiß nicht, was besser ist, aber ich denke, das ist vor allem eine Frage des Geschmacks.