Diesmal findet ihr darin auch meinen Artikel zur JSF-Komponentenbibliothek PrimeFaces. Viel Spaß beim Lesen.

Der Vortrag “Der lachende Dritte? – PrimeFaces im Vergleich zu RichFaces und IceFaces” findet am Montag, 13. 9., 11:20 – 12:30 Uhr statt.

Gespannt bin ich auch auf das umfangreiche Konferenzprogramm mit zahlreichen interessanten Vorträgen und Referenten. Ausführliche Informationen zur Konferenz findet man unter http://www.herbstcampus.de/hc10/index.html

Ausgangsstellung: Ich hatte in meiner JSF-Oberfläche mit RichFaces einen modalen Dialog eingebaut, der unter anderem einen Editor enthalten soll. Eigentlich ganz easy, nichts besonderes. Der Code sah vereinfacht und gekürzt in etwa so aus:

1
2
3
4
5
6
7
8
9
10

<rich:modalPanel id="editpanel" autosized="true">
	<h:form>
		... (andere Komponenten) ...
		<rich:editor id="editor" width="400" height="100" value="#{myBean.dialogBeschreibung}" />
		<a4j:commandButton value="Speichern" action="#{myBean.dialogSpeichern}" 
			oncomplete="#{rich:component('editpanel')}.hide();" reRender="treepanel" />
		<a4j:commandButton value="Abbrechen"
			onclick="#{rich:component('editpanel')}.hide();return false;" />
	</h:form>
</rich:modalPanel>

Eigentlich alles ok, oder? Also gut, ‘mvn tomcat:redeploy’ … ein bisschen einwirken lassen … Firefox auf, testen. Der Dialog springt sofort auf, aber der Editor ist tot, nicht mal den Cursor kriegt man zum blinken. Und auch der ‘Speichern’-Knopf zeigt keine Reaktion.

Die Lösung (besser: den Workaround) liefert JBoss.org Issue RF-7477 bzw RF-5268: Im modalPanel ist domElementAttachment=”parent” zu setzen. Zeile 1 von oben sieht dann also so aus:

<rich:modalPanel id="editpanel" domElementAttachment="parent" autosized="true">

Was lernt man daraus? Keine Ahnung, wohl das was wir schon oft gelernt haben: “Kaum macht mans richtig, schon gehts …”

Die Validierung erfogt über Constraints, die als Annotationen angegeben werden. Es sind schon einige Constraints enthalten, für besondere Zwecke lassen sich eigene erstellen. Hier mal ein einfaches Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// (imports usw. weggelassen)
public class Kunde {
 
    @NotNull(message = "Ein Kunde muss einen Namen haben")
    private String nachname;
 
    @Past(message = "Geboren in der Zukunft?")
    private Date geburtstag;
 
    @Size(min=6, max=20)
    @NotNull
    private String passwort;
 
    // Getter Setter usw.
}

Highlights der Version 4 sind:

• Native Integration in JPA 2 und JSF 2 (für SEAM Experten nichts neues, hat dort schon mit Version 3 von Hibernate Validator funktioniert)
• Groups: Es lassen sich Gruppen definieren, welche die Validierung bestimmter Constraints anstoßen
• Typsicherheit: Es wird sichergestellt, dass ein Constraint zum Datentyp des Properties passt.
• stark verbesserte Testsuite
• uvm. …

Noch ein Hinweis: Hibernate Validator kann unabhängig von einer Verwendung des Hibernate ORM eingesetzt werden.

Meine Empfehlung: Unbedingt anschauen!

• Andy Schwartz’s Weblog – What’s New in JSF 2? (exzellente Übersicht!)
• Max Katz: Learning JSF2: Managed beans (erster Teil einer Einführungsserie)
• Max Katz: Learning JSF2: Navigation (zweiter Teil der Einführungsserie)
• Max Katz: Learning JSF2: Ajax in JSF – using f:ajax tag (Teil 3)
• Ed Burns: JSF2 Facelet Tag Handlers
• Adventures in JSF 2.0: Hello World Tutorial using Maven 2, JSF 2, Facelets 2, and Weld
• Kostenloses Online-Buch zu JSF 2.0 von irian.at
• www.javaserverfaces.org – das soll die Seite als Einstieg für alle JSF-Programmierer werden! Entdeckt habe ich sie via http://ocpsoft.com/java/jsf-java/jsf2-engaging-the-community/ (dort findet man im Übrigen PrettyFaces, eine Erweiterung für “schöne” URLs bei JSF-Anwendungen)

To be continued … (freue mich über jeden interessanten Link!!!)

• Elemente für das Seitenlayout (wie Header, Footer, Sidebar etc.)
• Elemente für das Seitendesign unter Verwendung von Yahoo UI CSS Grid
• Endlich ein Element für eine Farbauswahl (ColorPicker)

Schon allein wegen der zahlreichen Bugfixes werde ich wohl in aktuellen Projekten auf die neue Version umstellen. Inwiefern ich die neuen Dinge zum Seitenlayout und -design brauchen kann, weiß ich noch nicht. Muss ich mir genauer ansehen, mein erster Eindruck ist, dass man da mit altbewährtem genau so gut fährt.

Damit wird es sehr einfach unter Java serverbasiert Karten in JSF-Applikationen zu integrieren. Das ganze wurde unter Verwendung des RichFaces CDK implementiert und sieht in den ersten Demos schon sehr ordentlich aus.

Ausprobiert habe ich es noch nicht, vielleicht kann ich es in einem kommenden Projekt nutzen; dann werde ich auf jeden Fall hier wieder berichten.

[Update 18.12.09:] Sollte es speziell um Google Maps gehen, empfiehlt es sich vielleicht das GMaps4JSF Projekt in Betracht zu ziehen.

Also erst mal das A4J-Logging aktiviert:

<a4j:log popup="false" level="ALL" style="width: 800px; height: 300px;"/>

Und siehe da, schon erhält man eine Ausgabe, die ich nach kurzem Grübeln entschlüsseln konnte: Query preparation for form ‘null’ requested: Ja klar! Ich hatte doch tatsächlich die umschließenden form-Tags vergessen!

Also schnell die <h:form> und </h:form> drum herum und wieder bewahrheitet sich die alte Weisheit “Kaum macht man es richtig, schon geht es!”

Wo wir schon bei Weisheiten sind: Manchmal sieht man eben vor lauter Bäumen den Wald nicht mehr.

Die Tabelle listet Personen auf, beim Doppelklick auf eine Zeile soll eine Maske zur Bearbeitung der selektierten Person geöffnet werden. In diesem Fall wurde nicht die “normale” DataTable verwendet, sondern die ExtendedDataTable. Sie sieht in etwa so aus:

Zuerst der Codeausschnitt der JSF-Seite:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<h:form id="personen">
    <rich:extendedDataTable value="#{personListBean.fullPersonList}"
        var="person" id="persontable" 
        width="886px" height="400px" sortMode="single" selectionMode="single" >
        <a4j:support event="onRowDblClick" action="#{PersonEditBean.prepareEdit}">
            <f:setPropertyActionListener value="#{person}"
                target="#{PersonEditBean.selectedPerson}" />
        </a4j:support>
        <rich:column sortable="true" sortBy="#{person.nachname}"
            filterBy="#{person.nachname}" filterEvent="onkeyup"
            width="170px" label="Nachname">
            <f:facet name="header">
                <h:outputText value="Nachname"/>
            </f:facet>
            <h:outputText value="#{person.nachname}"/>
        </rich:column> 
        <rich:column sortable="true" sortBy="#{person.vorname}">
        <!-- [...] -->
        <!-- [weitere Columns ...] -->
    </rich:extendedDataTable>
</h:form>

Der entscheidende Code:
In Zeile 3 wird über var=”person” die Variable für die verknüpften Instanzen in den Zeilen angelegt.
Die Zeilen 5 bis 8 definieren das AJAX Doppelklick Event. Als Action wird im PersonEditBean die Methode prepareEdit() angegeben. Dort geschieht eigentlich nichts weiter als das Umkopieren der Werte. Damit überhaupt die richtige (also die doppelgeklickte) Person verwendet wird, ist der PropertyActionListener nötig (Zeile 6 und 7).

Bleibt noch zu klären, wie denn nun die Maske zum Editieren der Person zum Zuge kommt. Dies wurde hier einfach mit einer klassischen Navigation geregelt; hier der Ausschnitt aus der faces-config.xml:

1
2
3
4
5
6
7
8
9

<navigation-rule>
    <from-view-id>/[...]/personen.jsp</from-view-id>
    <navigation-case>
        <from-action>#{PersonEditBean.prepareEdit}</from-action>
        <from-outcome>prepare_erfolgreich</from-outcome>
        <to-view-id>/[...]/editperson.jsp</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

Die prepareEdit() Methode liefert als Ergebnis den String “prepare_erfolgreich” und schon wird weitergeleitet. Immer? Eigentlich schon, lediglich der Internet Explorer will mal wieder nicht. Dagegen hilft aber Zeile 7 (“<redirect/>”). Vielen Dank für diesen Hinweis aus Ralph’s Java Blog!