Thoughts on agile software development
The FreshMarker Template Engine works with an interpolation system that only takes the type of a variable into account at evaluation time. This approach makes the use of variables in FreshMarker very flexible, but occasionally leads to runtime errors. These can be avoided if the type of a variable can be checked beforehand.
The FreshMarker Plug-In Mechanism was one of the first features to be realized for the template engine. The idea behind it was simple. With a proper plug-in mechanism, a new feature can be easily realized and integrated and if it fits the core functionality, it stays in FreshMarker. Otherwise it becomes an independent plug-in. This is how FreshMarker File, FreshMarker Money and FreshMarker Random were created. It also created the internal FreshMarker support for Version, Locale, Year, MonthYear, MonthDay, Duration, Period and some other classes.
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.