Yeah, I have been talking about template engines for months, and obviously, I haven’t washed this taste out of my mouth. So perhaps I just need to keep thinking aloud here.

Let’s go back and re-evaluate the purpose or goals of the MVC design pattern, shall we?

While we have the goal that code— programatic logic like model access and business rules— should be kept out of the view, it isn’t just for prettier organization. It is a separation of concerns, or a division of responsibilities.

You want the graphic designers to create, maintain and own the template files and the database weenies to do the same with the components in the back-end model. We don’t want any stepping on toes, here.

I’ve been advocating StringTemplate as an ideal for doing the “view” on J2EE web applications.

• You can’t do any code or programatic logic, even if you wanted to.
• Displayed data fields are not tags, so they show up in a design/layout tool as text, as in $first_name$
• Has a clever, non-programatic, way of doing loops over lists of data

But I now have two significant issues with my previously held assumptions.

First, graphic designers aren’t stupid. The ability to program Javascript, CSS and keep all the browser-differences in the front of their heads clearly places them in the non-stupid category. We don’t necessarily have to baby them.

Second, graphic designers are busy, and like us, they like to use tools that allow them to get their creative output out of their heads and into production as quick as possible. So while they could program in straight HTML, how has the time? Instead, they’ll use web authoring tools like Dreamweaver. So the view shouldn’t necessarily look the best in the code, but look and work well in the tools of the trade.

Third, what about rules or logic that affect the view? Should the order of a list of people be determined in the controller, the model, or the view? In working with most template engines, I could suck up a list from my database (without specifying a ORDER BY SQL directive) and send it directly to my view. The template page would then, during the listing code, specify a sorting order.

Here’s a better example. Let’s suppose on a previous form, the client has selected 4 items, and on the current form we are going to display those 4 items, but with an extra field. In our template scheme we issue the “loop” that will iterate over the four items allowing us to create the extra fields. But what is the name of these new fields? Clearly we want something like extrafield-1 and extrafield-2, etc.

Similar to ordering, we could either address this in full programmatic style (keep an index counter, and increment its value for each of the 4 items), or add a feature of the original loop construct that kept a counter for us.

From these three points, StringTemplate is now not necessarily the best choice, since it is relatively new and isn’t supported with a Dreamweaver extension. But it is this third point that troubles me the most. Should I bother Terrence to put ordering and a counter (and anything else I might need) in his looping construct, or do we fall back to having a full programming language inside.

If I am going to need a programming language, then I don’t want to screw around learning a 3/4 language like EL or Freemarker, I would just as soon use Java. So maybe the best choice is using JSPs as it is supported by most tools and does allow view-specific code…

If I was building a system, like a blogging engine, where my user’s were editing their own templates through a web interface (and not using a layout tools), then StringTemplate may be the best choice.

I still need to do some stewing.