Die iText Bibliothek enthält zwei Klassen, die es erlauben, HTML in iText Elemente zu übersetzen, HTMLParser und HTMLWorker. Der Parser ist gedacht für das Parsen von kompletten HTML Dokumenten, während der Worker benutzt werden sollte, wenn nur Auszüge von HTML Code eingelesen werden soll. Beide sind recht begrenzt in ihren Möglichkeiten, reichen aber aus für einfach formatierten Text (z.B. kursiver oder fetter Text, verschiedene Textfarben und -größen, hier die unterstützten HTML Tags). Der iText Autor empfiehlt andere Produkte, sobald die Ansprüche an die HTML2PDF Konvertierung steigen (sehr aussichtsreich scheint die Kombination aus iText zusammen mit dem Flying Saucer XHTML Renderer (Homepage des Flying Saucer Projekts).
Um nun einen String einfachen HTMLs zu parsen und in iText Elemente zu übersetzen, ist ein einfacher Aufruf der parseToList Methode des HTMLWorkers nötig.
htmlText = "<p><span style='font-size:6px'>Guten</span> <span style='color: rgb(255, 102, 0);'><strong>Tag</strong></span></p>";
bodyText = (ArrayList< Element >)HTMLWorker.parseToList(new StringReader(htmlText), null);
bodyText enthält nun eine Liste mit einem Paragraph, der aus zwei Chunks besteht, die jeweils die gesetzten Eigenschaften (Schriftgröße, Farbe) besitzen. Die Elemente der Liste können nun z.B. einem ColumnText (hier textCol) hinzugefügt werden.
for (Element element : bodyText) {
textCol.addElement(element);
}Ein denkbarer Einsatzzweck wäre die Bearbeitung des PDF Inhalts vor dem Erzeugen des Dokuments im FCKEditor mit einem entsprechend auf einfache Textformatierungswerkzeuge begrenzten ToolbarSet.
Anmerkung zur Unterstützung der Textgröße (font-size): In der aktuellen iText Version 2.1.5 sorgt ein Bug dafür, dass die Schriftgröße auf 8px gesetzt wird, sobald die Eigenschaft “font-size” verwendet wird. Dieser Bug wurde mit Revision 3895 gefixt.
Posted in Allgemeines | Tagged HTML, iText, PDF
Eine Datenbank schön zu befragen geht zum Beispiel mit der Hibernate Criteria API unter Benutzung der Factory-Klasse Restrictions. So lässt sich beispielsweise die Anfrage für eine etwas umfangreichere Such- und Filterfunktion so zusammenbasteln:
import org.hibernate.Criteria;
import org.hibernate.criterion.Order;
import org.hibernate.criterion.Restrictions;
[...]
List< Kunde > gefundeneKunden = sessionFactory.getCurrentSession()
.createCriteria(Kunde.class)
.add(Restrictions.ne("inaktiv", true))
.add(Restrictions.in("typ", search.getSelectedTypes()))
.add(Restrictions.eq("geschlecht", search.getGenderFilter()))
.add(Restrictions.between("datumLetzterKauf",search.getFromDate(),search.getUntilDate()))
.add(Restrictions.disjunction()
.add(Restrictions.like("name", "%"+search.getSearchStringName()+"%"))
.add(Restrictions.like("ort", "%"+search.getSearchStringOrt()+"%"))
.add(Restrictions.like("plz", "%"+search.getSearchStringPlz()+"%")))
.addOrder(Order.asc("name"));
.setMaxResults(search.getMaxResults())
.list();
Posted in Allgemeines
Soweit mir bekannt (und bei mir zu umfassendem Erfolg führend) gibt es drei Einstellungen, die man beachten muss, um seiner in Tomcat laufende Anwendung UTF-8 beizubringen.
1) Tomcat sollte die URL (und damit u.a. GET-Parameter) als UTF-8 kodieren. Dies wird über das URIEncoding Attribut des Connector Elements in der server.xml eingestellt.
<connector connectionTimeout="20000"
port="8080"
protocol="HTTP/1.1"
redirectPort="8443"
URIEncoding="UTF-8"/>
2) Das richtige Encoding der Request (und damit unter anderem der POST Daten eines Forms) wird mit einem CharacterEncodingFilter in der web.xml sichergestellt. Dieser sollte als einer der ersten Filter eingerichtet werden (das filter-mapping Element des charsetFilter also im Deployment Descriptor vor den anderen Mappings stehen).
<filter>
<filtername>charsetFilter</filtername>
<filterclass>org.springframework.web.filter.CharacterEncodingFilter</filterclass>
<initparam>
<paramname>encoding</paramname>
<paramvalue>UTF-8</paramvalue>
</initparam>
<initparam>
<paramname>forceEncoding</paramname>
<paramvalue>true</paramvalue>
</initparam>
<filtermapping>
<filtername>charsetFilter</filtername>
<urlpattern>/*</urlpattern>
</filtermapping>
</filter>
3) Um schon von vornherein allen Beteiligten (z.B. dem Browser) die Möglichkeit zu geben, die richtige Kodierung zu benutzen, sollte in den ausgelieferten HTML Seiten das verwendete CharacterEncoding vermerkt sein. Dies geschieht in JSPs so:
< %@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
und endet in der HTML Seite so:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Damit sollte nun alles auf UTF-8 eingerichtet und auf UTF-8 gefasst sein, damit zum Beispiel Umlaute und sonstige Zeichen korrekt dargestellt und verarbeitet werden können.
Posted in Allgemeines | Tagged CharacterEncodingFilter, Encoding, Filter, UTF-8, web.xml
Wie auch im API Eintrag zur @RequestMapping Annotation zu finden ist, lassen sich grobe Mappings auf Typebene (z.B. @RequestMapping("/kunden/*")) auf Methodenebene weiter spezialisieren. Dabei lässt sich als Parameter neben dem relativen Pfad (z.B. anlegen.do) auch die Art der Request angeben. Mappings könnten also so aussehen:
@RequestMapping(value="bearbeiten.do", method = RequestMethod.GET)
...
@RequestMapping(value="bearbeiten.do", method = RequestMethod.POST)
In einer Klasse, von der mehrere Controller erben, können dann Methoden implementiert werden, die unter gleichem relativen Pfad aufgerufen werden sollen. Das finale Mapping wird dann zusammengesetzt aus dem @RequestMapping auf Typebene der erbenden Klassen und dem relativen Pfad im @RequestMapping der Methode. Das ist nicht wirklich überraschend, dennoch gerade hilfreich.
Posted in Allgemeines | Tagged DefaultAnnotationHandlerMapping, RequestMapping, Spring
Bisher hat meine Spring Anwendung ausschließlich Tiles2 als View Technologie benutzt. Dazu habe ich einen UrlBasedViewResolver konfiguriert wie folgt.
applicationContext.xml
<bean id="viewResolver"
class="org.springframework.web.servlet.view.UrlBasedViewResolver"
p:viewClass="org.springframework.web.servlet.view.tiles2.TilesView"
p:order="2">
</bean>
Details zur Einrichtung von Tiles ist in der Spring Dokumentation zu finden (2.5, 3.0). Die zugehörige Tiles Konfigurationsdateien enthalten die Tiles Definitions, die zum Rendern aus den Controllern angesprochen werden können und beschreiben, wie die ausgelieferte Seite zusammengesetzt werden soll.
Um PDF Dokumente zur Laufzeit zu erzeugen und dem Benutzer anzubieten, wird ein zweiter ViewResolver benötigt. Ich habe dazu einen ResourceBundleViewResolver hinzugefügt, der die Datei views.properties nutzt, um die richtige Viewklasse zu einem Viewnamen zu finden.
applicationContext.xml
<bean id="viewResolverPDF"
class="org.springframework.web.servlet.view.ResourceBundleViewResolver"
p:basename="views"
p:order="1">
</bean>
views.properties
AnschreibenPdf.class=de.springblog.projekt.view.pdfviews.AnschreibenPdf
AnlagePdf.class=de.springblog.projekt.view.pdfviews.AnlagePdf
Beide ViewResolver haben die Property order, die die Reihenfolge der Resolver festlegt. Zuerst wird geschaut, ob in der views.properties File ein Eintrag für den vom Controller zurückgegebenen Viewnamen passt (ResourceBundleViewResolver, order 1). Wenn keiner gefunden werden kann, wird versucht, den Viewnamen als Tiles Definition zu interpretieren (UrlBasedViewResolver, order 2).
Die in der views.properties genannten Klassen erweitern bzw. implementieren die abstrakte Klasse AbstractPdfView und vor allem deren abstrakte Methode buildPdfDocument, in der das PDF gebaut wird (mit Hilfe der iText Bibliothek).
Wird nun also für den zurückgegebenen Viewnamen (z.B. AnschreibenPdf) eine Viewklasse (entsprechend de.springblog.projekt.view.pdfviews.AnschreibenPdf) gefunden, wird die überschriebene Methode buildPdfDocument dieser Klasse aufgerufen und das PDF erzeugt.
Setzt man nun einen HTML Link auf eine PDF Datei, die auf eine Controller-Methode gemappt wird (zum Beispiel durch @RequestMapping) und gibt diese einen Viewnamen aus der views.properties zurück, so rendert die angegebene Klasse ein PDF und Spring liefert dieses an den Browser aus.
Posted in Allgemeines | Tagged iText, PDF, Spring, Tiles, ViewResolver