Template Engines


Early years

When our senior engineers started developing browser-based applications in Perl and then Java more than a decade back, we were aghast at the way HTML tags were embedded in the code written by most programmers. These were pre-CSS days, so if a developer needed to change the appearance of a word on screen, he had to change code. The code too became totally unreadable, with page after page of println statements with HTML tags. There had to be a better way.

Roll Our Own

We created our own template library for Perl/CGI programmers which would simply load a text file and patch strings into it. The text file contained an HTML fragment with placeholder tags. The patching function would accept a hashmap with key-value pairs and replace keys in the HTML fragment with their values. It was extremely simple but adequate and we developed large applications entirely with this template patching engine. Our Perl code did not have a single embedded HTML tag.

When we started writing Java code, we encountered JSP and saw how business logic was being intimately mixed with HTML tags. We found this practice equally unacceptable. We therefore rejected JSP completely and moved to pure servlets. These servlets would contain only the business logic but no HTML tags. They would read text files containing page templates and would patch them using a patching function. This patching function used regular expressions and string processing, an area which was weak in Java at the time. So we integrated a Perl interpreter into Java using a freely available module, and wrote our template patching functions in Perl.

Modern template systems

We have moved away from Perl/CGI for new browser-based applications. For Java applications, we have moved to STRUTS2 and Velocity. We extensively use the power of Velocity for generating output pages, including Velocity macros where needed.