Thymeleaf ohne Servlet in Standalone-Anwendungen nutzen

Thymeleaf ist eine Template Engine, welche für die Nutzung mittels Java (oder anderer JVM-Sprachen) gedacht ist. Über diese können entsprechende Templates geschrieben werden, anschließend gefüllt und genutzt werden. Thymeleaf verfügt über eine Dokumentation, allerdings fehlt mir dort ein minimales Beispiel für Anwendungen, welche sich nicht im Web (sogenannte non-web environments) abspielen.

thymeleaf.org

Für ein minimales Beispiel wird natürlich ein Template benötigt. Dieses wird hier als HTML definiert:

<!DOCTYPE html>
<html>
<head>
    <title th:text="${title}"></title>
</head>
<body>
</body>
</html>

Interessant ist hierbei das Feld title, welches wir mit einem Titel füllen wollen. Im Java-Quellcode sieht die Implementation wie folgt aus:

ClassLoaderTemplateResolver resolver = new ClassLoaderTemplateResolver();
resolver.setPrefix("templates/");
resolver.setTemplateMode("HTML5");
resolver.setSuffix(".html");

TemplateEngine templateEngine = new TemplateEngine();
templateEngine.setTemplateResolver(resolver);

Context context = new Context(Locale.GERMAN);
context.setVariable("title", "Ein minimales Beispiel");

final String content = templateEngine.process("header.html", context);

Im ersten Schritt wird mit dem ClassLoaderTemplateResolver ein Resolver definiert, welcher schlussendlich dafür sorgt die Templates aus den Ressourcen (im resources-Ordner) bezogen werden. Daneben wird der Template-Modus eingestellt. Neben dem Modus HTML5 unterstützt Thymeleaf wie z.B. TEXT oder JAVASCRIPT. Danach wird die Template Engine erstellt und ihr der Resolver zugewiesen. Die Variablen, welche in diesem Fall im Template genutzt werden, werden über den Context definiert und gesetzt. Anschließend wird das Ganze an die process-Methode der Template Engine übergeben. Als Ergebnis erhalten wir im String content folgenden Inhalt:

<!DOCTYPE html>
<html>
<head>
    <title">Ein minimales Beispiel</title>
</head>
<body>
</body>
</html>

Damit wurde Thymeleaf in einer minimalen Variante angewendet. Die offizielle Seite der Template Engine ist unter thymeleaf.org zu finden. Lizenziert ist Thymeleaf unter der Apache License in der Version 2.0 und damit freie Software.

Waipoua-Theme für den Podlove Publisher anpassen

Seit meinem letzten Wechsel des Designs auf seeseekey.net nutze ich eine stark modifizierte Version des Elmastudio-Themes Waipoua. Neben Anpassungen am Design wurden unter anderem die externen Einbindungen der Google Fonts deaktiviert. In den aktuellen Themes von Elmastudio werden diese leider immer noch extern eingebunden; was wohl auch auf absehbare Zeit so bleibt.

Leider hat das Waipoua-Theme einige Probleme mit dem Plugin Podlove Publisher. Der Podlove Publisher ist ein Plugin, welches einen Workflow für Podcasts, vom Anbieten bis zum Abonnieren bereitstellt.

Podlove Podcast Publisher
Preis: Kostenlos

Das erste Problem mit dem Podlove Publisher im Zusammenhang mit dem Waipoua-Theme ist die Anzeige der von Beiträgen mit dem Post Type podcast auf der Startseite. In den Experteneinstellungen des Podlove Publishers ist dies die Einstellung Blog und Podcast kombinieren. Damit dies mit dem Waipoua-Theme funktioniert muss die Datei index.php des Themes angepasst werden. Dort findet sich folgende Quelltextblock:

<?php /* Start the Loop */ ?>
<?php global $query_string;
query_posts( $query_string . '&ignore_sticky_posts=1' ); ?>

  <?php while ( have_posts() ) : the_post(); ?>

    <?php get_template_part( 'content', get_post_format() ); ?>

  <?php endwhile; // end of the loop. ?>

<?php wp_reset_query(); // reset the query ?>

An dieser Stelle werden sämtliche Manipulationen der Abfrage entfernt. Anschließend sollte der Code so aussehen:

<?php /* Start the Loop */ ?>

  <?php while ( have_posts() ) : the_post(); ?>

    <?php get_template_part( 'content', get_post_format() ); ?>

  <?php endwhile; // end of the loop. ?>

Nach dieser Modifikation tauchen die Beiträge mit dem Post Type podcast in der Beitragsliste im Startmenü auf. Das nächste Problem betrifft die Darstellung der Beiträge mit dem Post Type podcast, sobald diese einzeln angezeigt werden. Hierbei wird das Design zerschossen, da der Beitrag in voller Breite angezeigt wird. Eine Sidebar würde in diesem Szenario nach unten rutschen.

Nach dem Fix funktionieren die Einzelseiten mit dem Post Type podcast

Um dies zu verhindern muss die Datei header.php angepasst werden. Dort findet sich nach dem schließenden head-Tag die Zeile:

<body <?php body_class(); ?>>

Diese Zeile wird entfernt und stattdessen durch folgenden Quellcode ersetzt:

// Fix problem with single posts (post type: podcast)
$body_class = get_body_class();

// single-podcast exists in body class, replace
if (in_array("single-podcast", $body_class)) {

  echo "<body class=\"";

  foreach($body_class as $body_class_value) {
    if ($body_class_value == "single-podcast") {
      $body_class_value = "single-post";
    }

    echo $body_class_value . " ";
  }
  
  echo "\" >";
}
else {
?>
  <body <?php body_class(); ?>>
<?php
}
?>

Der Quellcode sorgt dafür das die Klasse single-podcast in single-post umbenannt wird. Damit greift das CSS für gewöhnliche Beiträge und die Darstellung der Podcast-Seiten funktioniert ohne Probleme. Als letzten Schritt habe ich die archive.php angepasst. In der Datei wurde der komplette header-Block entfernt. Diese Anpassung ist im Gegensatz zu den anderen Anpassungen Geschmackssache. Sie sorgt dafür das keinerlei Archivtexte mehr auftauchen.

Swagger – REST API goes Framework

Ein REST-API von Hand entwickelt, benötigt eine Dokumentation, ein entsprechenden Server und eventuell einige Clients als Referenz. Einfacher wird es mit einem Framework wie Swagger. Unter Zuhilfenahme der Beschreibungssprache YAML können mit Hilfe des Frameworks REST-APIs, Dokumentation, Server und Clients generiert werden.

Der Swagger Editor

Der Swagger Editor

Doch Swagger versteht sich nicht nur als Framework, sondern auch als Spezifikation. Begonnen wurde mit der Entwicklung bereits im 2010; die Swagger Specification trägt seit Anfang Januar 2012 offiziell den Namen OpenAPI Specification und beschreibt eine maschinenlesbare Interfacedefinitionen einer REST-API. Ähnliches wurde unter anderem schon mit WSDL und WADL versucht – alles Konzepte bzw. Beschreibungsprachen welche an ihren eigenen Limitationen gescheitert sind und wenn überhaupt nur noch sporadisch genutzt werden.

Betreut und weiterentwickelt wird die Spezifikation nun von der Open API Initiative, zu der namenhafte Firmen wie Google, PayPal, IBM, Atlassian und Microsoft gehören. Die Spezifikation als solche ist freie Software und auf GitHub zu finden. Sie ist unter der Apache Lizenz lizenziert. Aktuell ist die Spezifikation in der Version 2.0 veröffentlicht.

Auf der offiziellen Webseite von Swagger findet sich ein Editor, mit welchem APIs definiert werden können und anschließend exportiert werden können. Der Editor kann dabei Server unter anderem in den Sprachen bzw. für die Framworks Haskel, Jax-RS, Node.js, Python, Rails und PHP erzeugen. Bei den Clients ist die Auswahl noch größer. Diese können in C#, HTML, Dart, Go, Groovy, Java, Javascript, Objective C, Perl, PHP, Ruby, Scala, Swift und vielen weiteren Sprachen erzeugt werden.

Neben dem Editor kann für die Erzeugung von Clients auch der Swagger Codegen genutzt werden. Dabei handelt es sich um eine Java-Anwendung um die Clients lokal auf dem eigenen Rechner zu erzeugen. Der Editor und viele weitere Tools rund um Swagger sind ebenfalls auf GitHub zu finden. – auch diese sind freie Software, welche unter der Apache Lizenz stehen.

3D-Stadtsimulation im Browser

Sim City sollte jedem der sich halbwegs für Spiele interessiert ein Begriff sein. Dabei handelt es sich um eine ursprünglich zweidimensionale Simulation einer Stadt. Das klassische Sim City wurde vor einigen Jahren in Form von Micropolis unter einer freien Lizenz veröffentlicht. Mit 3d.city wurde dieses Prinzip nun in die dritte Dimension und in den Browser befördert.

3d.city am Beispiel einer kleinen Stadt

3d.city am Beispiel einer kleinen Stadt

Für die Simulation nutzt 3d.city die Javascript-Implementation micropolisJS bzw. baut darauf auf und nutzt für die 3D-Darstellung die three.js-Engine. Das Spiel ist unter der GPL lizenziert und damit freie Software. Der Quelltext ist auf GitHub zu finden. Ausprobiert werden kann 3d.city unter lo-th.github.io/3d.city/.

Target Blank

Auch wenn Target Blank ein schöner Name für einen Actionfilm wäre, soll es hier stattdessen um das entsprechende HTML-Attribut:

target="_blank"

gehen. Mit Hilfe dieses Attributes kann man den Browser anweisen die verlinkte URL in einem extra Fenster (bzw. einem Tab) zu öffnen. In einem interessanten Artikel der vor knapp einen Monat erschien geht es um Argumente gehen dieses Attribut, bzw. die Nutzung desselben. Das bezeichneste Argument in dem Artikel, ist wie ich finde, die Tatsache das der Nutzer bei der Nutzung des Attributes bevormundet wird. Schließlich kann der Nutzer selber festlegen ob er einen Artikel in einem extra Tab öffnen möchte. Aus diesem Grund sollten wir die Nutzung von target=“_blank“ in Zukunft einfach unterlassen.