Thoughts on agile software development
Anyone working with monetary amounts in Java should definitely take a look at the Moneta project. A long time ago there was an article on this subject – JSR 354 – Your number for the money. Surprisingly, however, I had forgotten about Moneta support for FreshMarker. I’ll make up for that now.
Some blog posts are about ideas and not solutions. This has the pleasant advantage for the author that the content of the contribution does not (yet) have to work. It also saves the developer work if the audience does not appreciate the topic. When working with templates, there are always a number of variables that are processed in a template with always the same value. It would be nice if you could save computing time there.
I really like it when I can add new features to FreshMarker, especially if they are easy to implement and integrate elegantly into the overall system.
The last article described how the .version variable in FreshMarker can always be kept up to date. In this article, we want to simplify the use of the variable.
As the .version variable was previously of the string type, it was only possible to work with the string comparison operators and built-ins.
FreshMarker is strongly characterised by KISS and YAGNI. This makes the template engine lean and yet powerful. But in some places, the simplicity leads to careless mistakes.
In the first versions, the system variable .version was defined as a constant for the FreshMarker version. Unfortunately, this meant that the version number was regularly forgotten to be updated before the release.
With Partial Template Reduction, the template is filled with a fraction of the necessary data and thus simplified as far as possible. This articel presents the first part of the implementation.
I am proud to announce the release of FreshMarker 1.0.0! Having started as a small example for blog posts two years ago, FreshMarker has evolved into a robust and versatile framework designed to meet diverse templating needs.
FreshMarker is an embedded Java template engine that focusses on extensibility and simplicity. For this reason, every implementation of an extension is associated with weighing up its pros and cons. For a long time, the import directive therefore remained an unrealised feature.
While reviewing the mutation tests for FreshMarker, I noticed an implementation gap in the logical expression. So if something needs to be changed, why not quickly add something new.
Some additions to a framework are so trivial that they don’t really deserve their own article. On the other hand, as a developer, you may ask yourself why this addition has taken so long. For unknown data types, FreshMarker uses the interpretation of the class as a Java Bean by default. This is a good solution for many POJO, DTO and Entity classes, but in some cases the class should be used as a primitive FreshMarker type.