Thoughts on agile software development
The first part of this series introduced the new FreshMarker compiler and compared it against the tree-walking interpreter. This second part zooms in on Stage 1, the untyped compiler, and shows exactly what code it emits, how the class is assembled
FreshMarker 3.0.0 will introduce an ahead-of-time (AOT) and just-in-time (JIT) template compiler. This first post in a three-part series explains what changes under the hood, what you gain, and what you give up compared to the classic interpreter.
Macro-based templates often need a sensible default body for the common case, while still allowing customization at the call site. FreshMarker 3.0.0 will support exactly that: <#nested/> can carry inline fallback content that renders automatically when no caller body is provided.
This article explains how the feature is implemented, from grammar to runtime, and includes a design note on one carefully chosen trade-off.
Memory management is a major challenge when it comes to improving the performance of Java applications. When many objects are created, memory must be allocated for them; these objects must be managed and eventually deleted, and their memory released. This comes at a cost, and an application that consistently works with fresh objects will suffer from reduced performance.
With Freshmarker 2.7.0, the PooledTemplateProcessor has been added, which guarantees a performance boost in template processing; however, this comes at the cost of compromises elsewhere.
FreshMarker now supports passing parameters into Nested directives inside Macro directives. The previous article discussed the new feature and its capabilities. This post focuses on the technical implementation and outlines the necessary changes from the parser to runtime.
After two months of development, I’m pleased to announce the release of FreshMarker version 2.7.0. This time, the focus was on functional hash processing, more flexible formatting, and a major step toward a more consistent template syntax. Overall, it’s a well-rounded mix of new expression capabilities and improved code quality in templates. New Features Deprecation … Read more
While designing a new feature, I once again stumbled upon a feature of the template language that I haven’t liked for a long time. The syntax of the directives is modeled after HTML elements, not XML elements. As long as you don’t want to change the syntax of the template language, this isn’t a problem. But if you have a great idea for a new feature, you’re in for a world of trouble.
One of the most useful optimizations in FreshMarker is partial reduction: templates can be partially evaluated in advance if part of the model is already known. Until now, however, partial reduction had a blind spot—List directives with ranges (1..4, 4..1, 1..) were ignored during reduction and passed through as simple, non-reducing fragments. This changes with version 2.7.0.
In the FreshMarker template engine, hashes are a central data structure. Hashes access data via a name. Up until version 2.6.0, FreshMarker only supported hashes that used strings as names. Hashes that allow enums as names now exist, but their integration is far from complete.
When replicating the concepts of another template engine, there are always moments when you put off working on a particular concept. This rarely has anything to do with the complexity of the concept itself, but often stems from a personal aversion. For FreshMarker, this has meant that some concepts have been implemented late or completely reworked. Some concepts are still awaiting implementation. One of these concepts is the parameters of the nested directive, which will be implemented for FreshMarker 2.7.0.