Snippetory, templating platform
Snippetory is an extensible templating solution for the JVM. This rises the question:
There are so many template engines. Why yet another one?
Considering general template engines (vs bound to XML) I think there is great variety in two groups of solutions. There are script based template engines with a more or less complete language to fill out them selves with the data they get. The other group are the very simple projects with great separation of templating and logic, but almost nothing else.
Snippetory tries to get the best of both wolrds. It provides all the features a modern templating solution should provide. And it moves the binding code out of the template, so all the great java tool set can be used with it.Snippetory provides this key features:
Snippetory has a second important trait: an integrated repository for organizing and reusing the template code in a formerly unexperienced manner. Logic and presentation are separated by an opaque abstraction layer. So, let's start with the omnipresent 'Hello World':
So what do we see?
OK, let's calm down a bit. The sense of Hello world is being simple and it was simple, so mission completed.
To get a step further I thought of somewhat more complex. As this is not a tool
for the simple things I choose something really complicated:
Another thing that might confuse is the locale parameter. Many template engine don't offer a standard way to handle the locale. I don't understand that. Template engines are often used in user interface and has to convert types to strings. And converting a date to a string to a date is language dependent.
Finally we use another Syntax here. This allows the template to compile as java code.
/// mock mock meta data repeated area
The binding code:
Why use Snippetory?
Snippetory moves the binding code out of the template, and relies on your JVM language for binding. This massively reduces the number of additonal constucts Snippetory has to introduce. No variable declarations, no macros, no directives, no path navigation. Only regions, locations and a little bit meta data.
It's not primitive.
Even though there are a number of simple template engines around, they tend to get stuck when things get a little more complicated because the abstraction layer is simple, too. All the escaping and formatting is done out of context. Or to be honest, in many cases escaping is omitted.
It's a repositoryIt can be used some data belonging to your output. For instance in our pre-localized email template, we can store the subject. Or having many outputs in one file, maybe if one wants get SQL statements out of source. When ever there is a bunch of texts to handle Snippetory may help.
It's generalSnippetory is not bound to any output format. It has build-in support for HTML, other XML, formatted, human readable plain text, fixed field length and limited code generation support. I would even say it's best of bread in being general.
It's a text handling platformThere are many things one can replace while still taking advantage of others. However, when getting into it, it looses quite a bit of it's simplicity. But it enables a number of uses I never thought of.
It java basedOn first sight omitting an own scripting language looks like a disadvantage. It's so inflexible, in XY I can change without so much more without changing java. Mh, what exactly means: Without changing java??? If this is important how cute is Assembler? One can do so much without changing any java. Of course, to replace a JSP page you need some java AND a template. However the combination gains the full power of java. I wrote a web reporting solution. And it wouldn't have worked without that feature.
Enjoy!Head, Founder and chief technology evangelist of
Java, and all Java-based marks are trademarks or registered trademarks of Oracle.
This site is not affiliated in any way with Oracle.