Well over a year ago, I mentioned that I was working on a Velocity bundle for Textmate. Or, to be more precise: I mentioned that I’d already written one that we were using at NPG.

A year later, I’m ready to release the bundle; you can get it from its Google Code site. But before you go there, an explanation for the delay is in order – and on the way, I’ll tell you about how the bundle was written.

Problem: there’s no Velocity (VTL) bundle for Textmate.

Solution: write one yourself.

I’m currently working on a basic Velocity bundle for Textmate. We use it as a templating language at work, and, let’s face it, Textmate is an awesome editor with many, many ways to make your life easier. Given that it’s listed as a bundle people might be interested in… I’d better get started on it, right?

If you’re interested, leave a comment or drop me an email. So far I’ve got some basic function and syntax highlighting, along with autocompletion of some common constructs. Once it’s more finalised – and has been built in accordance to the VTL spec, not just the way I write it, I’ll start putting out releases.

(And if none of this makes much sense: Velocity/VTL is a templating language for Java web-apps. It’s one of the least sucky Java templating languages, apparently, but it’s not as mature of fully-featured as, say, Smarty.)

One thing most web applications need is a static page template. Now, whilst the page content might be static, the template itself might need to be dynamic – either because it’s going to change in future, or because you’ve got dynamic user information that appears in the tempalte.

So the most obvious way around this is the static controller. Dead easy, this: generate a new controller called static (or whatever you want). Then just write views for it named after pages you want. For instance: your about.rhtml file can contain all your “about” information. Then, when you hit up /static/about (to use the default routing), you get your static content, without having to make a whole page from scratch in public_html. You could even write a new 404 page on this controller.

All that remains, once it’s working, is to write some dedicated routes, and then the “static” controller can be hidden from existence – just route /about to :controller => "static", :action => "about" and you’re done. No need to write any controller logic at all!

Going on from there: one view I’ll always add to that template is the “foo” action.

So: when you’re mocking up a page, you’ll probably use lots of dummy links. Everyone expects this, because it’s obviously just a flat mock. But when you mock up an application, and show it to stakeholders in a working state, they click on things, and wonder why they get ActionController exceptions when it breaks. Also, they wonder why the link that breaks stuff is always /foo.

Obviously, it’s because I’ve left link_to "/foo" all over the shop. Have no fear: the easy way around this is to route /foo to :controller => "static", :action => "foo", and then write a static page called foo.

When you do this, the page should explain that it represents functionality that hasn’t been added yet, but will be added soon, and that the developers haven’t forgotten it.

This (from experience) reassures stakeholders that the thing that is not working will be working soon. It also means that when they do find “grey screen” errors, it either means that something’s genuinely broken, or it means that the developers really have forgotten something. Time to update that link to point to foo.

It sounds trivial, but it turned out to be an effective communication of diligence on the developer’s part, and saved much time in meetings explaining that “yes, we’re working on that”. Consider it, next time you’re developing for external stakeholders.