Category: Java

Problem: rich:editor eingebettet in rich:modalPanel

by Joachim Weinbrenner on 22.04.2010

Category: Java, JSF, RichFaces, Webentwicklung

Mal wieder so eine kleine Sache, an der man unnötig hängen bleibt und auf deren Lösung man ohne googeln kaum kommen kann.

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

UMLGraph in Javadoc mit Maven

by Joachim Weinbrenner on 29.03.2010

Category: Entwicklertools, Java, Open Source

Mit UMLGraph steht ein wunderbares, einfaches Tool zur Verfügung, um UML Klassendiagramme in die Javadoc Dokumentation einzufügen. Diese sind klickbar, d.h. man kann durch die Diagramme navigieren. Wer seine Projekte mit Maven erzeugt, integriert gerne auch die Javadoc-Erstellung in den Maven-Build. Und UMLGraph lässt sich da gleich ganz einfach mitnehmen.

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.

Zeichensatz festlegen bei generierten E-Mails

by Joachim Weinbrenner on 10.02.2010

Category: Java, PHP, SEAM, Spring, Webentwicklung

Programmierer habens oft eilig. Und sie gehen den Weg des geringsten Widerstands, was einfach geht, wird auch einfach gemacht. Bekanntes Beispiel: das Versenden von E-Mails aus der Applikation heraus, z.B. für Bestätigungsmails, Formularmailer usw.; in nahezu jeder Sprache gibt es dafür einfache Klassen oder Befehle, die eine E-Mail erzeugen und versenden.

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)

   ...

Die Beispiele sind bewusst kurz gehalten, das 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.

Hibernate Validator 4 – Validierung, wo sie hin gehört

by Joachim Weinbrenner on 24.10.2009

Category: Hibernate, Java, JPA, JSF

Vor gut zwei Wochen erschien die Version 4 des Hibernate Validators. Dabei handelt es sich um eine komplett neue Codebasis, es ist nun die Referenzimplementierung des JSR-303: Bean Validation. Der Hauptvorteil der Benutzung von Hibernate Validator ist, dass die Überprüfungen da stattfinden, wo sie maßgeblich sind, nämlich im Model. Statt also in allen Schichten (GUI/Web, Business Layer, Data Acess, …) eine eigene Prüfung zu implementieren (und sich damit leicht Inkonsistenzen und doppelten Code einzuhandeln) erfolgt die Validierung ausschließlich in den Domänen Objekten.

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!

← Older Entries
Newer Entries →