We use model driven software development in many places in the company. I think, some workmates (consultants ) do not really know that they only build a model that is generating the real application. But that’s OK. Some colleagues are working on a web application, were the web interface will be generated out of an description in XML. The same applies for the framework I use most the time. As I have a some experience in this area, I tried to tell them what works well and what does not. They asked me initially, but I do not think they wanted to hear the answer I gave them.

They like to use JSP as the view technology, but the lead architects forbade this, because of testability. So they looked after alternatives, like Velocity and FreeMarker. I told them to have a look at StringTemplate. That’s an amazing template engine. You can even say that it is the only real template engine that exits. There are some scientific paper from Terence Parr - who is professor of computer science at the University of San Francisco - that explain what a template engine should allow you to do and what it should not allow and why StringTemplate fits in this academic definition of template engines.

Look at this quote from the FreeMarker Site:

[...] you separate the designers (HTML authors) from the programmers. Everybody works on what they are good at. Designers can change the appearance of a page without programmers having to change or recompile code, because the application logic (Java programs) and page design (FreeMarker templates) are separated. Templates do not become polluted with complex program fragments. [...] it helps to keep the application clear and easily maintainable.

Does FreeMarker really fits in this description? According to Terence Parr it does not, because FreeMarker has some programming capabilities. “Some” is just too much here. Like with PHP or JSP, which are full blown programming languages you could work that way! But with a real template engine you have to work that way! Why do a HTML designers need to multiply numbers? Why do they need to make database querys? They do not need to. And that’s why nobody should need a template engine with “programming capabilities”. As everybody knows it is not easy to divide the template from the controller or renderer and it is not difficult to mix them together.

How often have you seen code like:

Your order from %<%= new SimpleDateFormat(“yyyy.MM.dd HH:mm:ss”).format(order.getDate()) >

That is to much logic for a template in opinion! Even if you move that into a Tag Lib or a Velocity or FreeMarker Macro like

Your order from #dateFormat(order.Date “yyyy.MM.dd HH:mm:ss”)

you have not really achieved anything in decoupling the template from the controller. Using StringTemplate you could only write

Your order from $order.Date$

and nothing more. That really decouples the template and the controller.

A question to the architects: Would you (unit) test these template? I think you can, because it’s really easy, but you would not, because you want to test the logic and not the template engine.

There is only one thing you could do with StringTemplate that you should not do:

This is <span style=“color:$colors.Red$”>bad</span> usage!

But remember the background: The web layer is generated from a description! Taking this into account you have to ask yourself which of two general ways you want to use. Do you want to generate one complete template for each view or do you want to compose the views out of many fragments?

I think the first one - generating complete pages - may have advantages according performance. Especially if you use JSP which is (according to the german magazine c’t) one of the fastest view technologies available. The greatest disadvantage is that you have to generate all views again and again if you change a template generating those views. Trust me: That’s really annoying. Have you ever spend a hour waiting for the generation of the applications just to determine that you had made a mistake?

So the main advantage of the second way - composing the views - is that you can change a template and the changed one will be used all over the place. It may have a slower performance at runtime, but this can be addressed using caching. You may even not have to generate code when using this solution. Because you can read the XML description and compose the views at runtime. When going that way, StringTemplate will be the best solution available, because of its abilities to reuse templates in a way you can not with Velocity, FreeMarker or JSP. StringTemplate is made to compose views out of fragments.

Last but not least, there may the a way to use both solutions. In a development environment you could use “composing” and you could use these templates to generate the complete templates for the production environment. But I would stick to the second solution.

Just my two cents.

A week ago I posted about a GroovyIBatisDao. Here I like to tell you about a few details as I announced.

At work we mainly use Java as general purpose language, but we also pay attention to groovy. There are other scripting languages which are more mature and with a much better syntax, but for our purpose - scripting some Java applications and frameworks - it’s best suited. (You may read a nice article from Fowler about that.)

In one case we use IBatis in the persistence layer and startet to write services which use our SqlMapDaos in Groovy. So I thought about an generic DAO for SQL-Maps using groovy. I had implemented a DAO using Spring Aspects before, like in this article about a generic Hibernate DAO. But this requires at least to define an interface for the DAO. But because Groovy it uses dynamic typing, we can even drop that also.

Groovy 1.5 ist out. It’s grooviest thing on earth. Far beyond the Grandfather of Funk himself, if you believe to the rumours and the ‘press’. Wow! It’s sooo groooovy and you really feel groovy if you’re elected to work with it.

I had some looks at groovy again and again since years. In theory it’s cool and I have many ideas where to use it. I developed some really groovy things in the past two weeks and I wanted to report about them here. But I only feel groovy when thinking about groovy. In theory.

Pratically I hate groovy, because I spend to much time on it, trying to run stupid unit tests in eclipse. The Eclipse Groovy plugin is shockingly terrible. At least it does not even compile my Groovy classes. Argh! Renaming a package which is used in a Groovy class crashes the whole IDE. Much wasted time.

Yes, groovy could be groovy, if there were a reasenable tooling we can use. (I have to stick with Eclipse.)

I hope I can report something positive soon.

Our blogroll took a little refresh. I moved out some links, where nothing happened for a longer time and introduced a new link to our workmate and Spring Framework Guru Nils Wloka. He’s running the little Spring related blog “Springify”.

I think there is some work left to do about our blogroll.