Standard Pattern für JSF (JavaMagazin)

[Gan...@j4fry.org]

This thread ws moved from our old sourceforge forum:

Standard Pattern für JSF (JavaMagazin)
By: ganesh (ganeshpuriProject Admin) - 2008-05-06 05:47
Heute erscheint der Atikel über JSF Standard Pattern. Wie üblich in
unserer schnellebigen Branche ist ein technischer Artikel schon
veraltet, wenn der Druck erscheint. In diesem Thread findet Ihr die
Upgrades. Hier zunächst mal eine Liste der Punkte, die jetzt schon
bekannt sind:

- Der Artikel erwähnt beim Row Method Pattern das Tomahawk Tag
t:updateActionListener. Mit JSF 1.2 verwendet man stattdessen das neue
Standardtag f:setPropertyActionListener

- Anstelle von Stacked Table Pattern sage ich inzwischen lieber Nested
Table Pattern
- Im Beispielprojekt auf der Begleit-CD wird zum Zugriff auf die JPG's
der Pfad /J4Fry_Quick_Setup_Tomcat_MyFaces_Hibernate/J4Fry/Resource/
*.jpg.faces verwendet. Es sollte aber J4Fry/Resource/*.jpg.faces
heißen, da das funktionieren des Zugriffs sonst davon abhängt, dass
der Context /J4Fry_Quick_Setup_Tomcat_MyFaces_Hibernate heißt. Also:
In den Dateien jsftree.jsp, jsftreeextensions.jsp und combo.jsp bitte /
J4Fry_Quick_Setup_Tomcat_MyFaces_Hibernate/J4Fry/Resource/*.jpg.faces
durch J4Fry/Resource/*.jpg.faces ersetzen.

- Das Beispielprojekt ist umgezogen und liegt nicht mehr in unserem
CVS Modul J4Fry_Quick_Setup_Tomcat_MyFaces_Hibernate, sondern jetzt
unter JSFExamples. Das ist nicht nur leichter zu merken, sondern liegt
auch daran, dass wir beim Upgrade auf JSF 1.2 auch von MyFaces auf
SUN's Referenzimplementierung mit dem kryptischen Namen Mojarra
(früher: RI) umgestiegen sind. Das neue Beispielprojekt enthält nicht
nur die .jars, die JSF 1.2 unterstützen, sondern hat in neuen Ordnern
dieselben Beispiele als Facelets Implementierungen.


RE: Standard Pattern für JSF (JavaMagazin)
By: Daniel Munzinger (munzi82) - 2008-05-09 09:32
Hallo,

ich habe zwei Fragen bezüglich des Row Method Patterns:

1. Mir ist die Problematik an dieser Stelle noch nicht so ganz
klar. Wenn ich der dataTable ein DataModel mitgebe, kann ich innerhalb
meiner BackingBean doch über myDataModel.getRowData() auf genau das
Objekt der Tabellenzeile zugreifen und habe dann auch Zugriff auf alle
Attribute etc.

2. Das actions keine Parameter im Sinne von Methodenparameter
übergeben werden können, stimmt an dieser Stelle. Ich kann einem
<h:command*> allerdings über <f:param name="myParams" value="1;2;3"/>
die Parameter in einer konkatenierten Notation mitgeben und dann in
der entsprechenden actionMethod aus dem Request auslesen und parsen.
Das ist sicherlich weitaus weniger komfortabel als "richtige"
Parameter (wie es z.B. JBoss Seam erlaubt), aber dass keine Parameter
mitgegeben werden können, stimmt so nicht ganz.

Grüße,
Daniel

RE: Standard Pattern für JSF (JavaMagazin)
By: ganesh (ganeshpuriProject Admin) - 2008-05-11 11:27
Hi Daniel,

Das sind beides eher Ergänzungen als Fragen, für die ich
mich herzlich bedanke. Neben f:setPropertyActionListener (JSF 1.2) und
t:updateActionListener (tomahawk) existiert also auch die Möglichkeit,
über ein DataModel oder über f:param die angeklickte Zeile einer
h:dataTable zu bestimmen.

Der Vollständigkeit halber möchte ich auch noch einen
weiteren Weg erwähnen, die angeklickte Zeile herauszufinden: Wenn in
der h:dataTable ein binding an eine UIData property der Backing Bean
definiert wird, läßt sich aus dem UIData Objekt per getRowIndex() die
selektierte Zeilennummer ermitteln, und mit dieser auf den Listenindex
zugreifen. Wer kein DataModel verwenden möchte, die getriggerte
Methode jedoch aus irgendeinem Grund nicht ins Zeilenobjekt legen kann
(z.B. JAXB-generierte Klassen?), kann so verfahren.

Ich verwende das DataModel nicht, weil ich das
Objektmodell des Webcontainers aus Pojos bauen möchte. Pojos (Plain
old Java Objects) sind einfache Java Klassen mit ein paar Attributen,
Gettern, Settern und ein paar Business Methoden. Ich vermeide die
Verwendung von komponentenspezifischen DataModels oder Wrapperklassen,
um so unnötige Zwischenlayers zu vermeiden und so die Komplexität der
Anwendung gering zu halten. Wenn Du Deine Methoden via Row Method
Pattern triggerst, bist Du direkt in der angeklickten Zeile und mußt
nicht erst das DataModel ansprechen und Dir über getRowData() die
Zeile besorgen, um dort die Methode aufzurufen.

Die Nachteile, die durch die Verwendung von f:param
entstehen, hast Du ja bereits selbst angeschnitten, aber auch dies ist
ein Weg, herauszufinden, welche Zeile der User geklickt hat.

Du also völlig recht damit, dass Row Method nicht der
einzige Weg ist, einen CommandLink in einer DataTable zu realisieren
und der Artikel an dieser Stelle unvollständig ist. Alle genannten
Alternativen haben gemein, dass zusätzliche Tags und/oder Klassen
benötigt werden. Mit Row Method ist der Zugriff meiner Ansicht nach am
einfachsten und direktesten. Ich möchte aber nicht ausschließen, dass
es Anwendungsfälle gibt, in denen eine der Alternativen Vorteile
bietet. Im Juni plane ich den Artikel auf unserer Website
veröffentlichen und dort die Alternativen aufzuzählen.

Viele Grüße aus München und nochmals Danke für Deinen
Ergänzungen,
Ganesh