Gedanken zur agilen Softwareentwicklung
Mit der Variableninterpolation erhalten die FreshMarker Templates einen ersten Schub von Dynamik. Durch Direktiven wird es darüber hinaus möglich, ganze Abschnitte eines Templates ein- und auszublenden oder mehrfach zu wiederholen. Die beiden bekanntesten Strukturen für solche Direktiven sollen hier mit ihrer Implementierung für FreshMarker vorgestellt werden.
Die FreshMarker Template-Engine, kann bislang nur konstante Inhalte ausgeben. Damit die Template-Engine nützlich wird, müssen variable Inhalte möglich werden. Ausdrücke der Form ${expression} werden von der FreshMarker Grammatik als Variableninterplolationen erkannt und durch das Ergebnis des Ausdrucks expression ersetzt.
Im ersten Beitrag wurde aus der Vogelperspektive beschrieben, wie die FreshMarker Template-Engine zu bedienen ist. Ausgelassen wurde dabei, wie aus der Textdarstellung eines Templates eine Instanz der Klasse Template generiert wird. Um ein Template syntaktisch korrekt und sauber zu verarbeiten, bietet es sich an, einen passenden Parser zu verwenden. Mit dem Parser-Generator JavaCC 21 von Jonathan Revusky steht das passende Werkzeug zum Erzeugen eines eigenen Parsers zur Verfügung. JavaCC 21 liefert erfreulicherweise auch eine eigene FreeMarker Grammatik, mit der die eigene Entwicklung zügig beginnen kann.
Dieser und weitere Beiträge werden sich mit der Template-Engine FreshMarker beschäftigen. Das Besondere an dieser Template-Engine ist, dass sie noch nicht existiert. Die Beiträge werden, parallel zur Entwicklung der Template-Engine, technische Entscheidungen und verwendete Konzepte beleuchten.
Die FreeMarker Template Engine ist eine hervorragende Bibliothek um eigene Inhalte Template-basiert zu erzeugen. Es existiert eine reichhaltige Anzahl von Funktionen um auch exotische Anforderungen erfüllen zu können. Manches Mal wünscht man sich jedoch zusätzliche Funktionalitäten um die eigenen Anforderungen besser umsetzen zu können. Wie erstaunt ist man dann jedoch, wenn diese Wünsche schon längst erfüllt wurden.
Der Java Compiler Compiler (kurz JavaCC) ist ein Parser Generator für die Java Entwicklung. Aus einer bestehenden Grammatik erstellt dieses Programm Java Code, mit dem Eingaben gegen diese Grammatik geprüft und verarbeitet werden können. Bei JavaCC handelt es sich um einen alten Bekannten, schon 2002 nutzte ich das Tool für die CSS2 Verarbeitung in einem embedded HTML Browser.
Durch den Einsatz von Spring Data JPA in eigenen Projekten können Datenbankaktionen sehr einfach mit Hilfe von Repository Interfaces umgesetzt werden. Alle Zugriffe auf die Entitäten erfolgen über Methoden dieser Schnittstellen. Mit diesen vordefinierten Zugriffsmethoden und der Möglichkeit eigene Zugriffsmethoden zu deklarieren ist ein Großteil der üblichen Anwendungen abgedeckt. Einziger Nachteil dieser Methoden ist ihre feste Definition. Ein alternativer Ansatz, um die Suchen dynamisch zu generieren, verwendet die Schnittstelle Specification.
Dieses Beitrag handelt nicht von dem bekannten Code Smell Refused Bequest (dem ausgeschlagenen Erbe), sondern von den vielen Featuren bekannter und unbekannter Bibliotheken, die in Vergessenheit geraten. Bei manchen dieser Bibliotheken wird man irgendwann auf die unangenehme Art auf die vergessenen Möglichkeiten hingewiesen. So wie jüngst die Bibliothek Log4j2 mit den Security Vulnerabilities CVE-2021-44228, CVE-2021-45046 und CVE-2021-45105.
Wenn es eine beliebte Sammlung von Bibliotheken für Java Entwickler gibt, dann ist dies wohl Apache Commons. Für jede Art von Problem eines Java Entwickler gibt es dort eine Methode, die eine einfache Lösung verspricht.
Schon im Beitrag Stammbaumprüfung mit BPMN wurde der Einsatz von BPMN Workflows in einer Workflow-Engine vorgestellt. Im damaligen Beitrag wurde die Workflow-Engine Flowable verwendet. In diesem Beitrag dreht es sich um die Workflow-Engine Camunda. Wer eine neuen Workflow erstellt hat, möchte diesen natürlich auch gerne im Vorfeld testen. Dafür stellt auch Camunda eine JUnit 5 Unterstützung bereit.