Some thoughts on Perl template processing
Tags: perl, webdev, cpan, templates
Published: 2021-11-02 14:19:29

---
title: Some thoughts on Perl template processing
published: true
date: 2021-11-02 14:00:00 UTC
tags: Perl,webdev,CPAN,templates
canonical_url: https://phoenixtrap.com/2021/11/02/template_processing_perl/
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pp08jhi58vmcr1tpjml7.JPG
---

[Template processors and engines](https://en.wikipedia.org/wiki/Template_processor) are one of those pieces of software where it seems every developer wants to reinvent the wheel. Goodness knows I’ve done it earlier in my career. Tell me if this sounds familiar:

1. You need to mix data into a document so you start with Perl’s string interpolation in `"`double quotes`"` or [`sprintf`](https://perldoc.perl.org/functions/sprintf) formats. (Or maybe you investigate [`format`s](https://perldoc.perl.org/perlform), but the [less said about them the better](https://metacpan.org/pod/Perl::Critic::Policy::Miscellanea::ProhibitFormats).)
2. You realize your documents need to display things based on certain conditions, or you want to loop over a list or some other structure.
3. You add these features via keyword parsing and escape characters, thinking it’s OK since this is just a small bespoke project.
4. Before you know it you’ve invented another [domain-specific language](https://en.wikipedia.org/wiki/Domain-specific_language) (DSL) and have to support it on top of the application you were trying to deliver in the first place.

Stop. Just stop. Decades of others who have walked this same path have already done this for you. Especially if you’re using a web framework like [Dancer](https://www.perldancer.org/), [Mojolicious](https://mojolicious.org/), or [Catalyst](http://www.catalystframework.org/), where the template processor is either built-in or pluggable from [CPAN](https://www.cpan.org/). Even if you’re not developing a web application there are several general-purpose options of various capabilities like [Template Toolkit](http://www.template-toolkit.org/) and [Template::Mustache](https://metacpan.org/pod/Template::Mustache). Investigate the alternatives and determine if they have the features, performance, and support you need. If you’re sure none of them truly meet your unique requirements, then maybe, _maybe_ consider rolling your own.

Whatever you decide, realize that as your application or website grows your investment in that selection will only deepen. Porting to a new template processor can be as challenging as porting any source code to a new programming language.

Unfortunately, there are about as many opinions on how to choose a template processor as there are template processors. For example, in 2013 Roland Koehler wrote a [good Python-oriented article on several considerations and the different approaches available](http://www.simple-is-better.org/template/index.html). Although he ended up developing his own (_quelle surprise_), he makes a good case that a template processor ought to at least provide various logic constructs as well as embedded expressions, if not a full programming language. Koehler specifically warns against the latter, though, as a template developer might change an application’s data model, to say nothing of the possibility of executing arbitrary destructive code.

I can appreciate this reasoning. I’ve successfully used Perl template processors like the aforementioned [Template::Toolkit](http://www.template-toolkit.org/) (which has both logic [directives](http://www.template-toolkit.org/docs/manual/Directives.html) and an [optional](http://www.tt2.org/docs/manual/Config.html#section_EVAL_PERL) facility for [evaluating Perl code](http://www.tt2.org/docs/manual/Directives.html#section_PERL)) and [Text::Xslate](https://metacpan.org/pod/Text::Xslate) (which supports [several template syntaxes](https://metacpan.org/pod/Text::Xslate#TEMPLATE-SYNTAX) including a [subset of Template::Toolkit](https://metacpan.org/pod/Text::Xslate::Syntax::TTerse)’, but without the ability to embed Perl code). We use the latter at work combined with [Text::Xslate::Bridge::TT2Like](https://metacpan.org/pod/Text::Xslate::Bridge::TT2Like)’s emulation of various Template::Toolkit [virtual methods](http://www.template-toolkit.org/docs/manual/VMethods.html) and it’s served us well.

But using those modules’ DSLs means more sophisticated tasks need extra time and effort finding the correct logic and expressions. This also assumes that their designer(s) have anticipated my needs either through built-in features or extensions. I’m already writing Perl; why should I switch to another, more limited language and environment provided I can remain disciplined enough to avoid issues like those described above by Koehler?

So for my personal projects, I favor template processors that use the full power of the Perl language like Mojolicious’ [embedded Perl](https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Embedded-Perl) renderer or the venerable [Text::Template](https://metacpan.org/pod/Text::Template) for non-web applications. It saves me time and I’ll likely want more than any DSL can provide. This may not apply to your situation, though, and I’m open to counter-arguments.

What’s your favorite template processor and why? Let me know in the comments.

* * *

_Cover image: [“making a template drawing to get a clear vision of the mask your masking”](https://www.flickr.com/photos/28860935@N02/7281882846) by [Douglas R Witt](https://www.flickr.com/photos/28860935@N02) is licensed under [CC BY-ND 2.0](https://creativecommons.org/licenses/by-nd/2.0/?ref=ccsearch&atype=rich)_