Eine fortgeschrittene JSF-Grafikkomponente erzeugen

Um einen Proxy auf dem Client zu instanziieren, müssen Bibliotheken zur Javascript-Unterstützung auf der Seite importiert werden. Um den Client so schlank wie möglich zu halten, sind die Javascript-Bibliotheken auf der Grundlage der Proxy-Klassen, die sie unterstützen, modular gegliedert. Daher müssen für jede Proxy-Klasse andere und sich möglicherweise überschneidende Gruppen von Bibliotheken importiert werden. Einer der schwierigen Teile beim Rendern von Charts ist die Phase, in der diese Script-Bibliotheken ausgegeben werden. Für jede Komponente erklärt der Renderer, welche Bibliothek sie erfordert, und er muss bei der Ausgabe der Bibliothekspräferenzen auf die vorher ausgegebenen Bibliotheken achten, um Duplikate zu vermeiden. Das wird von einem Script-Manager erledigt, der nur beim Rendern von Seiten existiert. Jedes Mal, wenn ein Renderer den Satz von Bibliotheksimporten ausgibt, übergibt er die Liste an den Script-Manager, der die Bibliotheken herausfiltert, die bereits ausgegeben wurden.

Scripting und Status-Synchronisierung

Die Aufgabe der clientseitigen Proxies liegt darin, Scripting zu ermöglichen und unnötige Seitenaktualisierungen zu vermeiden. Wenn der Chart erst gerendert ist, stehen die Proxies auf der Clientseite zur Verfügung, um dynamisch Interaktoren zu installieren und die Imagemap zu zeigen oder zu verbergen. Die Proxy-Objekte stehen auch regulären JSF-Komponenten zur Verfügung, die den Umgang mit Javascript-Maus-Ereignissen unterstützen.

Listing C:

Das Problem mit der lokalen Modifizierung des clientseitigen Proxies der Komponente liegt darin, dass dessen Status nicht mehr mit dem der Java-Komponente auf dem Server synchronisiert wird. Um dies zu lösen, verwenden die Proxies ein verstecktes Input-Tag (<INPUT TYPE=“HIDDEN“>), um den neuen Status auf dem Client zu speichern. Wenn eine Standard-JSF-Aktion ausgeführt und die Seite abgeschickt wird, dekodiert der Renderer diesen versteckten Status, so dass Client und Server synchronisiert sind. Dieses Verhalten erfordert ein spezielles Dekodier-Verhalten in der Renderer-Klasse. Die Standard-Dekodiermethode wird verbessert, um den Status, der vom Client kommt, zu dekodieren und den serverseitigen Komponentenstatus zu aktualisieren.

Komponenten-Abhängigkeiten

Die Verbindung zwischen dem Chart und der damit verbundenen Komponente wird durch ID-Referenzen oder Bindung erzeugt. Um ein flexibles Seitendesign zu erzielen, kann eine Komponente referenziert werden, bevor sie tatsächlich gerendert wird. Daher wird zum Zeitpunkt des Renderns, wenn eine Komponenten-Eigenschaft eine andere Komponente referenziert, die noch nicht gerendert wurde, die Ausgabe des Javascript-Codes verzögert. Der Javascript-Code löst diese Abhängigkeit beim Client auf, bis die referenzierte Komponente gerendert ist. Dies erledigt ein Dependency-Manager.

Zur Illustration folgt ein typischer Fall mit einem Überblick, der ein Chart referenziert.

Listing D:

Es gibt zwei Möglichkeiten:

• Die referenzierte Chart-Komponente ist bereits gerendert, dann gibt es hier kein Problem:

Listing E:

• Die referenzierte Chart-Komponente wird nicht vor der abhängigen Überblicks-Komponente gerendert. In diesem Fall wird ein Component-Creation-Listener beim Dependency-Manager registriert. Wenn der referenzierte Chart endlich gerendert wird, benachrichtigt sein Renderer den Dependency-Manager von dessen Erzeugung. Jetzt wird der Code ausgegeben, der für die Auflösung der Abhängigkeit gebraucht wird:

Listing F: