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.