Thoughts on agile software development
Whitespace in a template engine like FreshMarker’s is fundamentally different from the rest of the characters outside of it’s language constructs. A considerable amount of whitespace and line breaks are only used to ensure that the structure of the template remains comprehensible to the author.
A further step on the way to static templates is the automation of their creation. A Maven plugin can be used to convert the FreshMarker template sources into Java source code. Although there are now more modern build tools, Maven is still used in many projects. The first task of the Maven plugin should be the validation of template sources.
In previous articles on JUnit 5, various mechanisms were presented with which the JUnit tests could be made clearer. In this article, the ArgumentsAggregator is presented as an additional helpful mechanism.
As soon as the handling of optional values is built into FreshMarker, another interesting feature appears, which could be added with tiny changes. It was implemented in three steps, with the next step only becoming apparent once the previous step had been implemented. The whole thing started with the fact that empty optionals should be processed slightly differently than null values.
Agile software development is characterized, among other things, by the fact that features are developed on demand. This is one of the reasons why some features are not available in FreshMarker or are only added very late. Examples of late additions are the Include- and Import-Directives and the support of the StringBuilder and StringBuffer data types. For the former, the use case was not planned at the start of development and for the latter, support was simply forgotten. Another forgotten data type is the Optional class, which is now finally to be supported.
When updating some libraries that use FreshMarker, I was a bit surprised. The Hamcrest Matcher Generator library was still using Freemarker and also the library has never been published on Maven Central. Two things that should be fixed as soon as possible.
In the second article on the FreshMarker Compiler, we looked at the implementation of a pretty printer for Template instances. This implementation serves as the basis for the FreshMarker Compiler, which generates Java code from a Template instance. Before we tackle the Compiler, we need to look at a few more hurdles and details.
In the first article on static FreshMarker templates, some basic thoughts were put on paper. This article is intended to set a first milestone on the way to supporting much faster templates than before. As a nice side effect of this initial work, a pretty printer for FreshMarker templates will be created.
The template engine FreshMarker occupies a middle position in terms of processing speed for the benchmark displayed on the FreshMarker project page. In line with the concept of a dynamic, expandable engine, a noticeable acceleration of processing is not to be expected. The question therefore arises as to which concept can be thrown overboard in order to significantly increase speed.
The follow-up article on FreshMarker Features took a little longer because there was simply no feature that wanted to manifest itself in a plugin. In the FreshMarker Includes article, the features for activating and deactivating functionalities within FreshMarker were presented. The outlook was given that FreshMarker plugins should also be able to contribute their own features. How this can work is explained in this article.