Category: Java

Vortrag auf dem Herbstcampus 2010

Es freut mich sehr, dass ich auf dem kommenden Herbstcampus 2010 einen Vortrag halten darf. Ich werde die drei bekannten AJAX-JSF Frameworks PrimeFaces, RichFaces und IceFaces unter die Lupe nehmen und vergleichen.

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

Share

Problem: rich:editor eingebettet in rich:modalPanel

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

Share

UMLGraph in Javadoc mit Maven

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.

Share

Zeichensatz festlegen bei generierten E-Mails

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.

Share