Wer also ein Tippspiel zur WM oder zur Bundesliga mit Freunden oder Arbeitskollegen veranstalten möchte kann sich auf 11tipper.de eines einrichten.
Wer mehr über das Tippspiel an sich wissen möchte sollte den Artikel auf webthreads.de lesen oder sich die Features auf 11 Tipper direkt ansehen. Es bestehen auch zwei Demo Tipprunden in denen man als Spielleiter oder Tipper herumklicken kann.

Verwendete Frameworks

Jetzt noch ein paar Worte zur Technik. Das Tippspiel wird mit JSF 1.2 und JBoss Seam 2.2.0 entwickelt. Viele kennen JBoss Seam nur auf einem Application Server wie eben den JBoss AS. Ich habe Seam auf einem Tomcat 6 ohne Embedded JBoss verwendet. Es wird somit anstatt auf EJBs voll auf POJOs gesetzt und auch nicht so getan als wäre mann auf einem Application Server. Die Persistenz ist mit JPA (Hibernate) umgesetzt. Seam verwendet zur Validierung der Eingaben an der Oberfläche die JPA Annotationen an den Entities. Für Timer und zeitliche Verzögerungen wird Quarz verwendet. Das Frontend ist mit Facelets und JBoss RichFaces 3.3 umgesetzt. Verfeinert wird das Ganze mit viel Ajax und jQuery 1.4 als JavaScript Bibliothek.

In der Vergangenheit sind schon ein paar Artikel aus den Erkenntnissen dieses Projekts hier auf javathreads.de veröffentlicht worden. Und ich werde wohl noch das ein oder andere Tutorial dazu hier in naher Zukunft veröffentlichen. Falls jemand eine bestimmte Frage zur Umsetzung hat dann nur raus damit ich antworte garantiert =).

Vor allem bei der Frage was denn der Controller, gerade bei Web-Frameworks, sei gehen die Meinungen oft auseinander. Während man z.b. FAT Client Anwendungen den Controller oft direkt als erstes schreibt und diesen dadurch sehr genau bestimmen kann gehen die Meinungen was denn der Controller in JSF Anwendungen ist deutlich auseinander. Für JSF Anwendungen geht z.B. unter anderem die Meinung um, dass die Managed Bean (oder bei Verwendung von Seam eine Seam Action / Spring eine Spring Bean) der Controller ist. Auch die Aussage, dass die JSP/JSF/XHTML Seite oder der Browser der Controller ist (denn der Controller nimmt laut Definition die Eingaben entgegen und leitet sie weiter) waren darunter.

Nun bin ich bei Recherchen zu Seam über eine Präsentation von Roi Aldaag gestolpert und habe dabei folgende, meiner Meinung nach wirklich passende, MVC Beschreibung für JSF gesehen:

Man sieht darin, dass der Controller in einer JSF Anwendung aus mehreren Teilen besteht. Zum einen das FacesServlet, welches jeden Request entgegennimmt und initial verarbeitet. Je nach Situation wird anschließend die faces-config.xml verwendet um an das Model weiterzuleiten oder die in JSF möglichen Event Listener oder Action Handler aufgerufen.

Somit besteht der Controller aus drei Teilen:

• Front-Servlet (FacesServlet)
• Konfiguration (faces-config.xml oder pages.xml in Seam Anwendungen)
• Event Listener (z.B. ValueChangeListener)
• Action Event (ausgelöst durch h:commandButton und h:commandLink Actions)

Gerade das in JSF vorhandene Event Modell sowie die Action Events bringen JSF noch viel näher an das MVC Pattern als die bisherigen Web-Frameworks.

Nur der Vollständigkeit halber im folgenden noch eine kurze Erläuterung zu den Teilen Model und View:
Die View in einer JSF Anwendung beinhaltet:

• Component Tree (JSF Komponentenbaum)
• Component Model (Java Beans als Unterstützung für Komponenten)
• Delegates (Konverter, Validator oder Renderer)
• Resources (JSP, XML, Properties)

Das Model im MVC ist nicht ausschließlich das Domain Model oder Entity Modell gemeint. Mit Modell meint man die komplette Business Logik in einer Anwendung:

• Pojos (bei Plain JSF / Seam Pojo Anwendung)
• EJB, Entity Beans (bei einer JEE Anwendung)

Der Screenshot der MVC Umsetzung in einer JSF Anwendung ist aus der folgenden Präsentation mit dem Titel “JSF and Seam”:

Obwohl das Thema wohl wirklich ein alter Hut ist und der ein oder andere es wohl schon zum xten mal durchgekaut hat fand ich es wichtig MVC im Rahmen von JSF noch einmal aufzuzeigen ohne direkte Widerrede zu erhalten ;). In Meetings und persönlichen Diskussionen darüber brechen wir meistens ab da man sich doch nicht einigen kann, die Meinungen weit auseinander gehen und die Gemüter am Ende sehr erhitzt sind. Also falls jemand eine ergänzende oder gar total andere Meinung zu MVC hat darf er sich in den Kommentaren auslassen – es wird nichts zensiert ;).

Die komplette Präsentation dauert ungefähr eine Stunde.

So erscheint z.B. bei einem h:inputText Element bei dem das Attribut requrired="true" gesetzt ist die Meldung “Validation Error: Value is required.“. Entwickelt man eine Anwendung mit deutschem Frontend sollte dieser Text dann allerdings auch auf Deutsch dargestellt werden. Glücklicherweise bringt die JSF 1.2 Implementierung von Sun auch gleich ein deutsches Resource Bundle mit und der Ausgabetext heißt dann “Validierungs-Fehler: Wert wird benötigt.“.

Um eine Meldung zu erhalten muss der JSF Code wie folgt aussehen:

<h:inputText id="myInputField" value="#{myBean.myStringAttribute}" required="true"/>
<h:message for="myInputField"/>

Siehe auch in der JSF 1.2 Tag Library Documentation für h:inputText und h:message.

Nun aber zum eigentlichen Problem. Obwohl in der faces.xml lediglich eine deutsche Locale als unterstützt angegeben ist erscheint bei einem Konverterfehler ein englischer Text während bei einem Pflichtfeld ein deutscher Text erscheint. Hier die Angabe aus der faces.xml für die deutsche Locale:

  <locale-config>
   <default-locale>de</default-locale>
   <supported-locale>de</supported-locale>
  </locale-config>

Schaut man in das letzte verfügbare JSF 1.2 Update 12 APi Jar (jsf-api.jar) von Sun findet man im Package javax.faces alle Recource Bundle Dateien für die Fehlermeldungen (in früheren JSF 1.2 RI Releases sind die Resource Bundle Dateien in jsf-impl.jarMessages_de.propertiesJSF 1.2 RI – Resource Bundle. Schaut man sich diese an sieht man leider, dass lediglich die Validator Texte und übersetzt wurden. Die Converter Texte sind weiterhin in Englisch vorhanden.

Möchte man diese Texte nun in deutsch haben oder die Default Texte abändern reicht es aus in seiner eigenen Message Resource Bundle Datei die Keys zu überschreiben. Im folgenden alle vorgegebenen Converter und Validator Message Keys die man überschreiben kann eingedeutscht:

javax.faces.converter.BigDecimalConverter.DECIMAL={2}: ''{0}'' muss eine vorzeichenbehaftete Dezimalzahl sein.
javax.faces.converter.BigDecimalConverter.DECIMAL_detail={2}: ''{0}'' muss eine vorzeichenbehaftete Dezimalzahl die keine oder mehrere Stellen gefolgt von einem Dezimalpunkt und Nachkommastellen.  Beispiel: {1}
javax.faces.converter.BigIntegerConverter.BIGINTEGER={2}: ''{0}'' muss eine Zahl mit ein oder mehr Ziffern sein.
javax.faces.converter.BigIntegerConverter.BIGINTEGER_detail={2}: ''{0}'' muss eine Zahl mit ein oder mehr Ziffern sein. Beispiel: {1}
javax.faces.converter.BooleanConverter.BOOLEAN={1}: ''{0}'' muss entweder 'true' oder 'false'.
javax.faces.converter.BooleanConverter.BOOLEAN_detail={1}: ''{0}'' muss entweder 'true' oder 'false'. Jeder Wert anders als 'true' wird als 'false' interpretiert.
javax.faces.converter.ByteConverter.BYTE={2}: ''{0}'' muss eine Zahl zwischen 0 und 255 sein.
javax.faces.converter.ByteConverter.BYTE_detail={2}: ''{0}'' muss eine Zahl zwischen 0 und 255 sein. Beispiel: {1}
javax.faces.converter.CharacterConverter.CHARACTER={1}: ''{0}'' muss ein gültiges Zeichen sein.
javax.faces.converter.CharacterConverter.CHARACTER_detail={1}: ''{0}'' muss ein gültiges ASCII Zeichen sein.
javax.faces.converter.DateTimeConverter.DATE={2}: ''{0}'' ist ein ungültiges Datum. Beispiel: {1}
javax.faces.converter.DateTimeConverter.DATE_detail={2}: ''{0}'' ist ein ungültiges Datum. Beispiel: {1}
javax.faces.converter.DateTimeConverter.TIME={2}: ''{0}'' ist eine ungültige Zeitangabe.
javax.faces.converter.DateTimeConverter.TIME_detail={2}: ''{0}'' ist eine ungültige Zeitangabe. Example: {1}
javax.faces.converter.DateTimeConverter.DATETIME={2}: ''{0}'' ungültiges Datum und Zeitangabe.
javax.faces.converter.DateTimeConverter.DATETIME_detail={2}: ''{0}'' ungültiges Datum und Zeitangabe. Beispiel: {1}
javax.faces.converter.DateTimeConverter.PATTERN_TYPE={1}: Ein 'pattern' oder 'type' Attribute muss definiert werden um den Wert ''{0}'' zu konvertieren.
javax.faces.converter.DoubleConverter.DOUBLE={2}: ''{0}'' muss eine Zahl mit ein oder mehreren Ziffern sein.
javax.faces.converter.DoubleConverter.DOUBLE_detail={2}: ''{0}''  muss eine Zahl zwischen 4.9E-324 und 1.7976931348623157E308 sein. Beispiel: {1}
javax.faces.converter.EnumConverter.ENUM={2}: ''{0}'' muss zu einem Enum konvertierbar sein.
javax.faces.converter.EnumConverter.ENUM_detail={2}: ''{0}'' muss zu dem Enum konvertierbar sein, dass die Konstante  ''{1}'' entählt.
javax.faces.converter.EnumConverter.ENUM_NO_CLASS={1}: ''{0}'' muss zu einem Enum konvertierbar, aber keine Enum Klasse vorhanden.
javax.faces.converter.EnumConverter.ENUM_NO_CLASS_detail={1}: ''{0}'' muss zu einem Enum konvertierbar, aber keine Enum Klasse vorhanden.
javax.faces.converter.FloatConverter.FLOAT={2}: ''{0}'' muss eine Zahl mit ein oder mehreren Ziffern sein.
javax.faces.converter.FloatConverter.FLOAT_detail={2}: ''{0}'' muss eine Zahl zwischen 1.4E-45 und 3.4028235E38 sein. Beispiel: {1}
javax.faces.converter.IntegerConverter.INTEGER={2}: ''{0}'' muss eine Zahl mit ein oder mehreren Ziffern sein.
javax.faces.converter.IntegerConverter.INTEGER_detail={2}: ''{0}''  muss eine Zahl zwischen -2147483648 und 2147483647 sein. Beispiel: {1}
javax.faces.converter.LongConverter.LONG={2}: ''{0}'' muss eine Zahl mit ein oder mehreren Ziffern sein.
javax.faces.converter.LongConverter.LONG_detail={2}: ''{0}'' muss eine Zahl zwischen -9223372036854775808 und 9223372036854775807. Beispiel: {1}
javax.faces.converter.NumberConverter.CURRENCY={2}: ''{0}'' ist kein gültiges Währungszeichen.
javax.faces.converter.NumberConverter.CURRENCY_detail={2}: ''{0}'' ist kein gültiges Währungszeichen. Beispiel: {1}
javax.faces.converter.NumberConverter.PERCENT={2}: ''{0}'' ist keine gültige Prozentangabe.
javax.faces.converter.NumberConverter.PERCENT_detail={2}: ''{0}'' ist keine gültige Prozentangabe. Beispiel: {1}
javax.faces.converter.NumberConverter.NUMBER={2}: ''{0}'' ist keine Zahl.
javax.faces.converter.NumberConverter.NUMBER_detail={2}: ''{0}'' ist keine Zahl. Beispiel: {1}
javax.faces.converter.NumberConverter.PATTERN={2}: ''{0}'' ist kein Zahlenmuster.
javax.faces.converter.NumberConverter.PATTERN_detail={2}: ''{0}'' ist kein Zahlenmuster. Beispiel: {1}
javax.faces.converter.ShortConverter.SHORT={2}: ''{0}'' muss eine Zahl mit ein oder mehreren Ziffern sein.
javax.faces.converter.ShortConverter.SHORT_detail={2}: ''{0}'' muss eine Zahl zwischen -32768 und 32767. Beispiel: {1}
javax.faces.converter.STRING={1}: Konnte ''{0}'' nicht zu einem String konvertieren.

javax.faces.validator.DoubleRangeValidator.LIMIT=Validierungs-Fehler: Spezifiziertes Attribut kann nicht in einen Double-Typ umgewandelt werden.
javax.faces.validator.DoubleRangeValidator.MAXIMUM={1}: Validierungs-Fehler: Wert ist gru00F6u00DFer als zulu00E4ssiges Maximum ''{0}''.
javax.faces.validator.DoubleRangeValidator.MINIMUM={1}: Validierungs-Fehler: Wert ist kleiner als zulu00E4ssiges Minimum ''{0}''.
javax.faces.validator.DoubleRangeValidator.NOT_IN_RANGE={2}: Validation Error: Specified attribute is not between the expected values of {0} and {1}.
javax.faces.validator.DoubleRangeValidator.TYPE={0}: Validierungs-Fehler: Wert ist nicht vom richtigen Datentyp.
javax.faces.validator.LengthValidator.LIMIT=Validierungs-Fehler: Spezifiziertes Attribut kann nicht in korrekten Typ umgewandelt werden.
javax.faces.validator.LengthValidator.MAXIMUM={1}: Validierungs-Fehler: Wert ist gru00F6u00DFer als zulu00E4ssiges Maximum ''{0}''.
javax.faces.validator.LengthValidator.MINIMUM={1}: Validierungs-Fehler: Wert ist kleiner als zulu00E4ssiges Minimum ''{0}''.
javax.faces.validator.LongRangeValidator.LIMIT=Validierungs-Fehler: Spezifiziertes Attribut kann nicht in korrekten Typ umgewandelt werden.
javax.faces.validator.LongRangeValidator.MAXIMUM={1}: Validierungs-Fehler: Wert ist gru00F6u00DFer als zulu00E4ssiges Maximum ''{0}''.
javax.faces.validator.LongRangeValidator.MINIMUM={1}: Validierungs-Fehler: Wert ist kleiner als zulu00E4ssiges Minimum ''{0}''.
javax.faces.validator.LongRangeValidator.NOT_IN_RANGE={2}: Validation Error: Specified attribute is not between the expected values of {0} and {1}.
javax.faces.validator.LongRangeValidator.TYPE={0}: Validierungs-Fehler: Wert ist nicht vom richtigen Datentyp.
javax.faces.validator.RequiredValidator.FAILED=Validierungs-Fehler: Wert wird benu00F6tigt.
javax.faces.validator.NOT_IN_RANGE=Validierungs-Fehler: Spezifiziertes liegt nicht zwischen {0} und {1}.

Wer sich diese Datei im Originalzustand anschauen möchte kann sie sich hier herunterladen: Messages_de.properties
Wer meine Übersetzung direkt als Datei haben möchte kann sie sich hier herunterladen: Messages_de_angepasst.properties

Und da ich selbst immer wieder nach diesen Message Keys suche ist dieser Blog Artikel entstanden =).

Somit stehen jetzt Implementierungen nichts mehr im Weg und auch somit hat auch DZone direkt einen Spickzettel für JSF 2.0 (Cheat Sheet) in ihrer Rubrik DZone Refcardz herausgebracht:

Der Spickzettel kann dabei als ganz allgemeiner JSF Spickzettel angesehen werden aber er hebt die Erneuerungen durch JSF 2.0 an den verschiedenen Stellen deutlich hervor. Wie z.B. das neue Tag f:ajax oder f:viewParam:

Wie immer gilt, dass man sich für den PDF Download bei DZone registrieren muss aber es besteht auch die Möglichkeit sich den Spickzettel direkt online anzusehen. Wer sich nicht registrieren möchte dem steht frei hier einen Kommentar mit gültiger E-Mail zu hinterlassen und ich schicke ihm die Refcard direkt zu.

Das erste Webinar findet am Dienstag um 19 Uhr mit Pete Muir (Red Hat) statt und trägt den Titel “The new JSR299 – JCDI, Java Contexts and Dependency Injection“.

Das zweite Webinar findet am Donnerstag Dienstag den 19.05. um 18 Uhr mit Ed Burns (Sun) statt und trägt den Titel “JSF 2“.
[Update]
Hier die Präsentation (PDF Direktlink) zu dem JSF 2 Webinar.

Ich werde versuchen mir beide live anzusehen und falls das nicht klappt gibt es meißt die Möglichkeit sich im Nachhinein die Webinare noch einmal anzusehen. Wenn dem so ist werde ich hier noch notieren wie man an die Webinare nachträglich gelangt.

[Update 13.05.] Webinar JSF 2.0 mit Pete Muir wurde auf den 19.05. korrigiert.

Man kann den Funktionsumfang für die Formatierungsmöglichkeiten soweit abspecken, dass nur noch das nötigste für den Benutzer möglich ist:

Wer den Editor live ausprobieren möchte kann dies auf der RichFaces Live Demo direkt tun. Die einfachste Variante den Editor einzubinden und zu verwenden ist:

<rich:editor value="#{myBean.editorContent}"/>

Die Editor Komponente selbst basiert auf den sehr bekannten TinyMCE JavaScript WYSIWYG Editor und bisher musste man, wenn man einen solchen Rich Editor wollte, diesen manuell in sein Projekt einbinden.

Ich werde den Editor die Tage mal ausprobieren und dann wird man sehen ob er sich so einfach einbinden und verwenden lässt wie es bei den vielen anderen RichFaces Komponenten war.

Neben dem Editor ist noch eine weitere Ajax Komponente hinzugekommen: Ajax Queue. Mit dieser ist es möglich direkt hintereinander abgesetzte Ajax Request so zu managen, dass der zweite Ajax Request erst abgesetzt wird wenn der erste beendet wurde. Somit kann man parallele Ajax Requests verhindern.

Wer bisher noch nichts von den RichFaces bzw. das dazugehörige Ajax4Jsf gehört hat der sollte sich auf der Live Demo Seite die vielen Beispiele mal ansehen. Neben den fertigen Ajax Komponenten wie z.b. die DataTable, Inplace Edit, Tree oder File Upload (um nur einige zu nennen) ist vor allem der Ajax4Jsf Teil sehr interessant. Mit diesem lassen mit einfachen Mitteln bzw. Komponenten normale JSF Seiten “Ajaxifizieren” (a4j:support), es lassen sich JavaScript Methoden dynamisch erzeugen (a4j:jsfunction) die mit JSF Managed Beans reden oder Teile der JSF Seite neu Rendern oder man kann den Server mit Hilfe von Ajax Anfragen um z.B. einen Status abzufragen (a4j:poll).
Persönlich finde ich genau diesen Ajax4Jsf Teil und die gesamte Einfachheit der Verwendung der RichFaces Komponenten den Grund warum ich die JBoss RichFaces sehr empfehlen kann.

Noch ein letzter Tipp: Wer mit den RichFaces arbeitet sollte sich auf alle Fälle die JBoss Tools in Eclipse installieren um die direkte RichFaces Unterstützung im JSF Editor zu erhalten. Neben Autocomplete bei den Komponenten, dem Rich Editor für JSF oder xhtml Seiten erkennt er auch Expressions und kann auf die Methoden und Beans referenzieren.

Viel Spass beim ausprobieren!

Die erste Refcard beinhaltet die Grundlagen über Java Server Faces (JSF). Es wird der Entwicklunsprozess, der Lebenszyklus (Lifecycle), die Konfigurationsdatei faces-config.xml, die JSF Expression Language (EL) sowie die JSF Core und HTML Tags und noch einiges anderes aufgezeigt.

Die zweite Refcard beinhaltet die Gundlagen über Java Persistence API (JPA). Themen sind unter anderem das Objektrelationale Mapping, den EntityManager erhalten und verwenden, Transaktionen verwenden, Queries ausführen und noch einiges mehr.

Ich finde vor allem die JPA Refcard wirklich brauchbar. Es behandelt viele grundsätzliche Themen die man bei jedem Projekt, was mit JPA oder Hibernate durchführt, benötigt und dient dadurch wirklich als nützliche Hilfe. Man kann es auch sehr gut als Unterstützung in den Einstieg von JPA oder Hibernate verwenden, was natürlich auch für alle anderen Spickzettel gilt.

Die JSF Refcard behandelt auch viele grundsätzliche Themen, aber letztlich finde ich z.B. eine online TLD für die Tags z.b. wesentlich praktischer. Andererseits ist z.B. auch bei jedem Html Tag ein Screenshot der Komponente zu sehen, was zum Beispiel den Unterschied zwischen “h:selectOneListbox“, “h:selectOneMenu“, “h:selectManyListbox” und “h:selectManyMenu” schnell und deutlich hervorhebt. Viele verwechseln gerade bei diesen eben genannten immer gerne die Komponenten bzw. das daraus resultierende Html Ergebnis ;).

Neben den beiden hier vorgestellten Refcardz zu JSF und JPA sind schon eine Reihe anderer interessanter Spickzettel veröffentlicht worden. So findet man zum Beispiel Spickzettel zu “Dependency Injection in EJB 3“, “Design Patterns“, “Getting Started with Eclipse” oder für alle die mit RichFaces, Ajax und dadurch auch mit jQuery zu tun haben “jQuery Selectors“.

Man kann alle Refcardz auf refcardz.dzone.com herunterladen, muss allerdings leider erst registrieren. Falls sich das einer gänzlich sparen möchte schicke ich sie ihm auch gerne per Mail zu =).

Ein meiner Meinung nach sehr schönes Beispiel für eine solche Ajax Ladeanzeige bietet Google. Wer schon mit Google Anwendungen gearbeitet hat dem wird diese globale Ladeanzeige mittig oben im Browser durchaus bekannt sein:

Der Vorteil einer solchen globalen Ladeanzeige liegt darin, dass sie dem Anwender bekannt ist. Hat er sich einmal daran gewöhnt, dass sie mittig oben zu finden ist fällt sie ihm bei jedem erneutem Anzeigen eher ins Auge und er sieht sofort, dass eine Aktion im Hintergrund passiert.

Eine solche Ladeanzeige kann man sehr einfach mit Hilfe der JBoss RichFaces erstellen und in einer eigenen Anwendung für die Statusanzeige eines jeden Ajax Requests verwenden. Wie genau das angestellt wird ist im folgenden zu lesen.

Um unter Verwendung der JBoss RichFaces auf einen aktiven Ajax Request, der zum Beispiel durch einen a4j:commandButton oder a4j:commandLink ausgelöst wurde zu reagieren und einen Status anzuzeigen dient die RichFaces Komponente “a4j:status“. In der einfachsten Variante wird die a4j:status Komponente wie folgt erstellt:

<a4j:status id="commonstatus"  startText="In progress..." stopText="Finish"/>

Sobald ein Ajax Request durch einen CommandLink oder CommandButton gestartet wird reagiert diese Statuskomponente darauf und zeigt den Text “Wird geladen…”. Ist der Ajax Request beendet (und natürlich auch schon vor dem Ajax Request) wird der Text “Fertig” angezeigt.

Diese Komponente hat noch weitere Möglichkeiten genutzt zu werden. So können zum Beispiel ganze Html Blöcke ein und ausgeblendet werden anstatt nur ein Text, wie auch auf der RichFaces LiveDemo zu sehen.

Wir wollen aber in diesem Tutorial eine globale Ajax-Ladeanzeige verwenden und benötigen somit noch ein Html Fragment, welches uns das Ladebild und Text mittig oben im Browserfenster anzeigt.
Dazu wird ein div Element, dass mit CSS formatiert wird, erstellt. Dieses div Block muss natürlich auf jeder Seite vorhanden sein, die einen Ajax Request auslösen kann. Ich arbeite bei bei der Entwicklung einer JSF Anwendung immer mit Facelets und somit ist das verwendete Facelets Template (template.xhtml) der richtige Platz um diesen Code unterzubringen:

<div id="globalStatusDiv" style="display:none;">
  <img src="#{baseUri}/img/ajax-loader.gif" alt="Loading" />&#160;Loading..
</div>

Die dynamische Ajax Loading Grafik kann man sich bequem auf ajaxload.info generieren lassen und passend zu dem obigen Code Beispiel im Ordner img ablegen. Man kann an dieser Stelle natürlich auch wie bei JSF gewohnt die h:graphicImage Komponente verwenden.
Hier noch der Ausschnitt wie der Ausdruck #{baseUri} ausgewertet wird:

<html xmlns="http://www.w3.org/1999/xhtml"
  ...
  xmlns:c="http://java.sun.com/jstl/core">
  ...
  <c:set var="baseUri" value="#{facesContext.externalContext.requestContextPath}"/>
  ...

Dazu dazugehörige CSS wird separat in einer externen CSS Datei abgelegt:

* html body { margin: 0; overflow-y: hidden; padding: 0; }

#globalStatusDiv {
  position: fixed;
  top: 0;
  text-align: center;
  margin-left: auto;
  margin-right: auto;
  left: 50%;
  width: 100px;
  margin-left: -50px;
  height: 25px;
  line-height: 25px;
  background-color: #FFF;
  padding: 2px 15px 2px 10px;
  color: #000;
  font-family: Verdana,Arial,Helvetica,sans-serif;
  font-size: 12px;
  font-weight: bold;
  z-index: 10000;
  border: 1px solid #BBB;
  border-top: none;
}

#globalStatusDiv img {
  vertical-align: middle;
}

Nachdem nun das “GlobalStatus” div Element samt CSS Angaben definiert sind muss nun noch die Ajax4Jsf Status Komponente angepasst werden. Es soll nun nicht mehr der Text angezeigt werden sondern das “GlobalStatus” div ein- und ausgeblendet werden. Dazu bedienen wir uns der JavaScript Bibliothek jQuery, die mit den RichFaces gleich mitgeliefert wird. Damit das Beispiel funktioniert und wir die von den RichFaces mitgelieferte jQuery JavaScript Bibliothek nutzen können müssen wir die RichFaces “Script Load Strategy” von “DEFAULT” auf “ALL” in der web.xml abändern:

  <context-param>
    <param-name>org.richfaces.LoadScriptStrategy</param-name>
    <param-value>ALL</param-value>
  </context-param>

Damit werden immer alle JavaScript Resroucen auf jeder Seite geladen und nicht nur wenn eine RichFaces Komponente sie benötigt. Es bestehen hier natürlich mehrere, sogar viel bessere Lösungen als diese hier verwendete.

Anschließend die Ajax Status Komponente wie folgt abändern.

<a4j:status id="globalStatus" forceId="true" layout="none"
  onstart="jQuery('#globalStatusDiv').fadeIn('fast')"
  onstop="jQuery('#globalStatusDiv').fadeOut('slow')" />

Es wird nichts weiter gemacht als das “GlobalStatus” div-Block bei einem Ajax Request sichtbar zu machen (fadeIn()) und nach dem Request wieder auszublenden (fadeOut()). Mehr zu diesen Funktionen auch in der offiziellen jQuery Effects Dokumentation.

Nun fehlt nur noch eine Kleine Beispielseite. Dazu habe ich mir eine klein Bean mit einem Attribut erstellt, welcher mit Ajax gesetzt und anschließend ausgegeben werden wird.

Hier die Bean – ich verwende in diesem Beispiel JBoss Seam, daher wird mit der @Name Annotation gearbeitet. Die herkömmliche Bean Konfiguration durch die faces-config.xml funktioniert natürlich genauso.

package de.javathreads.helloworldseamprojekt.session;

import org.jboss.seam.annotations.Name;

@Name("editBean")
public class EditBean {

  private String name;

  public void setName(String name) {
    this.name = name;
  }

  public String getName() {
    return name;
  }
}

Und hier der interessantere Part – der Ausschnitt aus JSF Seite:

<h:form>
  <h:inputText value="#{editBean.name}" />
  <a4j:commandButton value="Speichern" reRender="viewNamePanel" status="globalStatus" />
</h:form>

<a4j:outputPanel id="viewNamePanel">
  Name: #{editBean.name}
</a4j:outputPanel>

Wichtig ist, dass bei der a4j:commandButton Komponente das Attribut status gesetzt ist. Mit diesem Attribut wird die a4j:status Komponente angegeben, die für diesen Ajax Request anzeigen soll.

Das Ergebnis sieht dann wie folgt aus. Beim absenden des Ajax Requests, hier durch Drücken das “Speichern” Buttons, erscheint die Loading Anzeige:

Ist der Request fertig und wurde der Ausgabe Bereich (Name anzeigen) neu gerendert verschwindet auch die Ladeanzeige:

Habe vor einiger Zeit Jing gesehen und wollte es schon immer mal ausprobieren – hier also das “live” Beispiel:

Das Layout des Statusanzeige oder Loadingblocks kann man natürlich komplette mit Hilfe von Html und CSS selbst bestimmen. Bei OpenWishes haben wir zum Beispiel eine gelbe Hintergrundgrafik gewählt. Und weil Jing soviel Spass gemacht hat kommt hier das Beispiel aus OpenWishes. Hier erscheint die Ladeanzeige während wenn man sich einen neuen Wunsch erstellen möchte und dazu die Produktwebseite angibt die anschließend geparst werden muss um die Informationen zu erhalten:

Für diesen Fehler gibt es viele Ursachen aber generell nur eine Begründung: Es existiert kein Formular welches um den Link, Button oder Bereich, im diesem Beispiel eine Tabelle, gespannt sein muss (<h:form>…</h:form>).
Vor allem bei der Verwendung von Ajax (Ajax4Jsf Tags) bzw. den RichFaces Komponenten wie der <a4j:commandLink> oder der <a4j:commandButton> sowie alle Komponenten die selbst intern auch Ajax verwenden wie z.b. die Sortierfunktion bei der Rich DataTable kommt dieser Fehler in der Entwicklung häufig vor.

In diesem Beispiel (Screenshot oben) wurde eine RichFaces DataTable mit Sortieren der Spalten verwendet. Im ersten Schritt erstellt man meist nur die DataTable (<rich:dataTable>…</rich:dataTable>) ohne Sortierung und dazu wird natürlich auch kein Formular benötigt. Um die Sortierung hinzuzufügen wird bei den einzelnen <rich:column> Elementen das Attribut sortBy="" hinzugefügt. So sieht der Source Code für eine solche Tabelle wie folgt aus:

  <div>
    <rich:dataTable id="userList"
       value="#{userList.resultList}"
       var="user"
       rendered="#{not empty userList.resultList}"
       style="margin-top: 20px; width: 500px;"
       columnsWidth="50px">

       <f:facet name="header">
          <rich:columnGroup>
            <rich:column colspan="2" style="text-align:left;">
              <h:outputText value="Alle konfigurierten User" />
              &#160;(#{userList.resultCount})
           </rich:column>
         </rich:columnGroup>
        </f:facet>

        <rich:column sortBy="#{user.id}">
            <f:facet name="header">Id</f:facet>
            <h:outputText value="#{user.id}"/>
        </rich:column>

        <rich:column sortBy="#{user.name}">
            <f:facet name="header">Name</f:facet>
            #{user.name}
        </rich:column>

      </rich:dataTable>
  </div>

Das Sortieren selbst wird mit Hilfe von Ajax durchgeführt. Ajax allein benötigt natürlich kein Formular allerdings benötigen die RichFaces Komponenten die mit Ajax funktionieren oder Ajax Funktionalität einbringen ein gültiges Formular. Der Grund liegt darin, dass fast immer etwas mit Ajax “submittet” werden soll um eine Aktion auzuführen. So kommt dieser “this._form is null” auch häufig bei der Verwendung der <a4j:commandLink> Komponente vor. Obwohl es aussieht wie ein normaler Html Link wird dennoch ein Formular submittet und somit ein <h:form> Tag benötigt.

So ist die Lösung für unsere Tabelle mit der Sortierfunktion relativ einfach:

  <div>
    <h:form>
      <rich:dataTable id="userList" ...>
        ...
      </rich:dataTable>
    </h:form>
  </div>

Noch ein kleiner Tipp am Rande: Verwendet man die Möglichkeit nach dem Ajax Request einen Bereich oder eine Komponente neu zu renderen (Attribut reRender) dann sollte man versuchen das <h:form> Tag außerhalb des neu zu rendernden Bereiches zu lassen. Zum Beispiel so:

  <div>
    <h:form>

      <a4j:outputPanel id="editUserPanel">
        <!-- Eingabefelder welche mit Ajax gespeichert wird -->
        <h:inputText value="#{user.name}"/>
        ...
      </a4j:outputPanel>

      <a4j:commandLink action="#{myBB.saveUser}" reRender="editUserPanel"/>

    </h:form>
  </div>

Setzt man das <h:form> Tag innerhalb des <a4j:outputPanel> Tags kann es nach dem neu Rendern auch vorkommen, dass dieser ominöse “this._form is null” Fehler auftritt.
Am besten fährt man, wenn die Formular Tags außerhalb solcher dynamischen Bereiche definiert sind. Möchte man die zu submittenden Daten für den Ajax Reqeust eingrenzen steht extra dafür die AjaxRegion Komponente (<a4j:region>) zur Verfügung.