1
2
3
4
5
6
7
8
9
10
11

import javax.script.ScriptEngineManager;
import javax.script.ScriptEngine;
 
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine jsEngine = mgr.getEngineByName("JavaScript");
try {
  Boolean result = jsEngine.eval("a=19; b=2; c=2; a>b && c==b");
  print "Ergebnis: " + result;
} catch (ScriptException ex) {
    ex.printStackTrace();
}

In diesem Fall wird Ergebnis: true auf der Konsole ausgegeben. Dies nur zur Inspiration – die Vielfalt der Möglichkeiten lässt sich nun bestimmt schon erahnen …

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>maven-jetty-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <connectors>
      <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
        <port>8088</port>
      </connector>
    </connectors>
    <webAppConfig>
      <contextPath>/</contextPath>
    </webAppConfig>
  </configuration>
</plugin>

Die Anwendung sollte nun unter http://localhost:8088/ verfügbar sein.

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 …”

Hier ein Beispiel, wie eine entsprechende Reporting-Sektion im pom.xml aussehen könnte:

<reporting>
  <outputDirectory>/ein/sinnvoller/pfad</outputDirectory>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-javadoc-plugin</artifactId>
      <configuration>
        <doclet>gr.spinellis.umlgraph.doclet.UmlGraphDoc</doclet>
        <docletArtifact>
          <groupId>gr.spinellis</groupId>
          <artifactId>UmlGraph</artifactId>
          <version>4.6</version>
        </docletArtifact>
        <additionalparam>
           -inferrel -inferdep -quiet -hide java.* -collpackages java.util.* -qualify
           -postfixpackage -nodefontsize 9
           -nodefontpackagesize 7
        </additionalparam>
      </configuration>
    </plugin>
  </plugins>
</reporting>

Und das Ergebnis kann sich sehen lassen:

Wer tiefer in die Materie, Parameter und Möglichkeiten von UMLGraph einsteigen möchte findet in der Onlinedokumentation ausführliche Hilfestellung.

Leider wird dabei häufig vergessen, den Zeichensatz der generierten Mail richtig (bzw. überhaupt) zu setzen. Hat eine Mail im Header kein Feld “Content-Type:” gesetzt, so handelt man sich zwei gravierende Probleme ein:

1. Der empfangende Client kann die Mail nicht richtig interpretieren, da er nicht weiß, in welcher Codierung der Inhalt der Mail ist. Das hat zur Folge, dass Umlaute, Sonderzeichen usw. nicht richtig angezeigt werden.
2. viele Spam-Filter werten dies als Negativ-Punkt, somit steigt die Wahrscheinlichkeit, dass die Mail ihren Empfänger nicht erreicht.

Ich schreibe hier mal beispielhaft für PHP, Java, Spring und SEAM, wie man den Header um die Content-Type Angabe ergänzen kann. Dabei beschränke ich mich der Einfachheit halber auf eine simple Textmail, also kein Multipart mit HTML oder Attachment (Beispiele dazu lassen sich schnell im Web finden).

PHP:

$header = 'MIME-Version: 1.0' . "\n" . 'Content-type: text/plain; charset=UTF-8' . "\n" . $strFrom;
mail($strEmpfaenger, $strSubject, $strMailtext, $header) or die("Die Mail konnte nicht versendet werden.");

Java:

MimeMessage message = new MimeMessage(session);
message.setHeader("Content-Type", "text/plain" + "; charset=" + "UTF-8");

Spring:

MimeMessage mimeMessage = ...
MimeMessageHelper message = new MimeMessageHelper(mimeMessage, "UTF-8");

SEAM: (ein Facelet-Template, das vom SEAM gerendert wird)

<m:message charset="UTF-8">
   ...
</m:message>

Die Beispiele sind bewusst kurz gehalten, dass Thema E-Mail-Programmierung kann wohl Bücher füllen. In erster Linie will ich Entwickler motivieren, bei aller Eile auch an die Kleinigkeiten zu denken.

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!!!)

• jvmstat 3.0 (enthält visualgc)
• Artikel auf heise Developer.

Dank ans heise Team, für den schönen Artikel!

Herausragend ist die Integration von Groovy zum Schreiben von Testscripten. So lassen sich Unit-Tests nach bewährtem Muster ganz einfach für Webservices implementieren und die Entwicklung wird kontinuierlich getestet.

Hier noch ein kleiner Artikel zu RESTClient von Subhash Chandran mit Code-Beispielen.

• 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.

Wer also Twitter in seine Java-Applikationen integrieren möchte, ist hier bestens bedient. Sogar ein Maven-Repo ist vorhanden.

Und es geht noch weiter: mit Log4Twitter hat Yamamoto einen Log4J-Appender geschrieben, mit dem sich Log4J-Ausgaben an einen Twitter-Account leiten lassen – dazu muss in der Anwendung nicht einmal was geändert werden, lediglich die Konfigurationsdatei von Log4J kriegt den passenden Eintrag. Und schon kann ich von überall die Fehlermeldungen meiner Software via Twitter abonnieren … und mit mir die ganze Welt!?

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.

Zunächst wurde über die Neuerungen im kommenden JSF2.0 diskutiert, mit der Quintessenz, dass vieles einfacher wird, aber nichts spektakulär Neues hinzu kommt. Viele Dinge, die man sich bisher über andere Frameworks/Tools ins Boot geholt hat, werden jetzt in den Standard integriert (z.B. Facelets). Die faces-config.xml lässt sich zukünftig auf ein Minimum reduzieren, da das meiste über Annotationen abgedeckt werden kann.

Im Anschluss ging die Diskussion um die Zukunft des Web (Web3.0?) zunächst um die Wünsche aus Entwicklersicht (z.B. RichClients im Web, …), die dann mehr und mehr in Richtung Anwendersicht abschweifte (“Was will der Anwender in Zukunft?”) sowie die Probleme mit persönlichen Daten in einer vernetzten Welt.

Klar wurde dabei in erster Linie, wie schwer es ist, über Übermorgen hinaus zu blicken. Insgesamt hat es sehr viel Spaß gemacht und ich freue mich auf das April-Treffen.

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!

Besonders schön ist die Orientierung an der JPA – wann immer Feinheiten von Hibernate, die darüber hinaus gehen besprochen werden, wird dies gesondert hervorgehoben. Die Beispiele sind nie komplexer als nötig und damit leicht verständlich, wenngleich an manchen Ecken etwas konstruiert wird.

Als “Extras” gibt es eine Einführung in Hibernate-Validator und -Search, einen Überblick über das Eclipse-Plugin Hibernate-Tools/JBoss-IDE, sowie eine Schnelleinführung in JBoss-Seam (wobei sich hier auch gleich Werbung für das neue Buch von Bernd Müller versteckt).