Hinter dem URL der ersten Strategie verbirgt sich ein Servlet (Listing 2), das den HTTP-Parameter form:eingabe ausliest, um eine Menge möglicher Benutzernamen zu laden. Damit die JavaScript-Klasse Autocompleter diese im Webbrowser anzeigen kann, müssen sie in einer ungeordneten HTML-Liste zurückgesendet werden (Listing 2). Da die JSF-URLs im Standard auf JSP-Dateien abgebildet sind, wurde ein Servlet verwendet. Allerdings ist es möglich, die Request-Verarbeitung der JSF-Engine zu überlassen.
Probleme der ersten Strategie
Für ein AJAX-basiertes Eingabefeld wird eine nicht unerhebliche Menge an Zusatzinformationen benötigt. Die im Beispiel eingebundenen JavaScript-Dateien benötigen ihrerseits wiederum weitere JavaScript-Dateien. Dies ist bei einer Portierung des Eingabefeldes auf andere JSPs nicht auf den ersten Blick ersichtlich. Bei Änderungen der IDs muss ebenfalls die JavaScript-Anweisung für den AJAX-Request geändert werden. Das Gleiche gilt für das <div>-Element. Ein weiteres Problem liegt bei der <h:inputText/>-Komponente. Moderne Webbrowser bieten oft selbst eine automatische Vervollständigung bei Eingabefeldern an. Dazu unterstützen sie das nicht standardisierte Attribut autocomplete. Setzt der Webentwickler seinen Wert auf off, wird die automatische Vervollständigung für das korrespondierende Eingabefeld nicht mehr angeboten. Leider besitzt die <h:inputText/>-Komponente erst in der JSF-Version 1.2 ein autocomplete-Attribut, sodass es mit JSF 1.1 zu Problemen bei der Eingabe kommen kann. Dieses sehr einfach gehaltene Beispiel verdeutlicht bereits die Notwendigkeit von einfach zu bedienenden AJAX-Komponenten, die einem Page Author die Arbeit erleichtern.
Eine AJAX-Komponente, die über einen Tag eingebunden wird und die sich selbst um die notwendigen Zusatzinformationen wie Ressourcen oder JavaScript-Anweisungen kümmert, nimmt dem Page Author viel Tipparbeit ab. Listing 3 zeigt eine JSP, die eine solche Komponente (<ajax:inputText/>) enthält. Es wird deutlich, dass diese JSP wesentlich kompakter ist. Neben dem Attribut value besitzt der Tag das resourceURL-Attribut, das auf das Servlet verweist. Um solch kompakte JSPs zu ermöglichen, muss der Component Writer eine Renderer-Klasse und einen speziellen Tag liefern. Eine eigene JSF-Komponente wird in diesem Beispiel nicht benötigt, da es sich bei der AJAX-Komponente um eine gewöhnliche Texteingabe handelt, sodass die Standard-JSF-Komponente wieder verwendet wird. Als Faustregel kann gesagt werden, dass neue Komponenten nur dann programmiert werden sollten, wenn es für das gewünschte Verhalten keine Komponente am Markt gibt. Der neue AJAX-Tag (Listing 4) verbindet also die Standard-Komponente mit dem neuen AJAX-Renderer. Er besitzt die Eigenschaften value und resourceURL und deren setter-Methoden, die den entsprechenden Attributwert aus der JSP entgegennehmen. Innerhalb der Methode getComponentType() wird die Verwendung der Standard-Eingabekomponente (javax.faces.Input) bestimmt. Die Methode getRendererType() gibt den Typ des eigens programmierten Renderers an. Innerhalb der Methode setProperties() werden die Werte des Tags an die JSF-Komponente übermittelt. Das Attribut resourceURL ist für unseren Fall eingeführt worden, um den URL des Servlets flexibel zu halten. Diese Eigenschaft ist allerdings nicht im Standard enthalten. Das stellt aber kein Problem dar, denn über die Anweisung component.getAttributes().put(attrName, value) können den JSF-Komponenten beliebige Attribute übergeben werden. Das Rendering der AJAX-Komponente wird durch den Renderer des Listings 5 übernommen. Die Methode decode() bewerkstelligt die Verarbeitung des HTTP-Requests, nach dem Drücken des Senden-Buttons. Die abgesendete Eingabe wird aus einer Map-Datenstruktur, die alle HTTP-Parameter enthält, gelesen und mit der Methode setSubmittedValue() an die Komponente übergeben. Diese Methode sollte nur innerhalb der decode()-Methode genutzt werden.
Die Methode encodeBegin() generiert das notwendige HTML. Als Erstes wird das Eingabefeld gerendert, dessen autocomplete-Attribut auf off gesetzt wird. Nach der Ausgabe des <div>-Elements folgt der interessanteste Teil, die JavaScript-Anweisung zum Absenden des AJAX-Requests. Der Autocompleter-Klasse werden innerhalb des Renderers dynamisch die drei Parameter übergeben. Die ID des Eingabefeldes wird durch die Anweisung component.getClientId(context) gewonnen. Für das <div>-Element wird dessen ID aus der Konstante DIV_ID ausgelesen und die URL des Servlets wird über die Map-Datenstruktur der Methode getAttributes() direkt aus der JSF-Komponente ausgelesen. Die Renderer-Klasse hat noch eine weitere Methode, die private Methode encodeResources(). Sie nutzt die eigens implementierte Hilfsklasse JSHelper, um die Ressourcen wie CSS- oder JavaScript-Dateien auszuliefern. Die statischen Methoden addJavaScript() und addCSS() machen nichts anderes, als URLs für JavaScript oder CSS zu rendern. Die Auslieferung erfolgt über einen Servlet-Filter. Die Idee zu einem Servlet-Filter für die Auslieferung von Ressourcen stammt aus dem Apache-MyFaces-Projekt. Allerdings sei angemerkt, dass ein Servlet-Filter innerhalb einer Portlet-Umgebung zu Problemen führen kann. Doch nun fragt sich der angehende Component Writer: "Wohin mit den JavaScript- und CSS-Dateien?". Die Antwort ist einfach: sie werden im gleichen Paket abgelegt wie die Klassen der AJAX-Komponente. Das hat den Vorteil, dass der Component Writer eine einzige JAR-Datei, statt etlicher Dateien, ausliefert. Konfiguriert wird die Komponente innerhalb der faces-config.xml-Datei.
