1 Some Reasons to Extend Thymeleaf
Thymeleaf is an extremely extensible library. The key to it is that mos t of its user-oriented features are not directly built
into its core, but rather just packag ed and componentized into feature sets called dialects.
The library offers you two dialects out-of-the-box: the Standard and the SpringStandard dialects, but you can easily
create your own. Let’s explore some of the reasons for doing this:
1.1. Scenario 1: adding features to the Standard dialects
Say your application uses the SpringStandard dialect and that it needs to show an alert text box in blue or red
background depending on the user’s role (admin or non-admin) from Monday to Saturday, but always in green on
Sundays. You can compute this with conditional expres sions on your template, but too many conditions could render
your code a little bit hard to read…
Solution: create a new attribute called alertclass and an attribute proces sor for it (Java code that will compute the
rig ht CSS clas s), and packag e it into your own MyOwnDialect dialect. Add this dialect to your template engine with the
th prefix (same as the SpringStandard one) and you’ll now be able to use th:alertclass="${user.role}" !
1.2. Scenario 2: view-layer components
Let’s say your company uses Thymeleaf extensively, and you want to create a repos itory of common functionalities
(tag s and/or attributes ) that you can use in several applications without having to copy-pas te them from one
application to the next. This is, you want to create view-layer components in a similar way to JSPs taglibs.
Solution: create a Thymeleaf dialect for each set of related functionalities, and add thes e dialects to your applications
as needed. Note that if the tag s or attributes in thes e dialects make use of externalized (internationalized) mes sages ,
you will be able to packag e these mess ag es along with your dialects (in the shape of processor messages) instead of
requiring that all of your applications include them in their mes sag es .properties files as you would with JSP.
1.3. Scenario 3: creating your own template system
Now imag ine your are creating a public webs ite that allows users to create their own des ig n templates for showing
their content. Of course, you don’t want your users to be able to do absolutely anything in their templates , not even all
that the Standard Dialect allows (for example, execute OGNL expres sions). So you need to offer your users the ability
to add to their templates only a very specific set of features that are under your control (like showing a profile photo,
a blog entry text, etc).
Solution: create a Thymeleaf dialect with the tag s or attributes you want your users to be able to use, like
<mysite:profilePhoto /> or <mysite:blogentries fromDate="23/4/2011" /> . Then allow your users to create
their own templates using thes e features and just let Thymeleaf execute them, being sure nobody will be doing what
they’re not allowed to.
