Files are the Currency of Web Development

We’re working with a new content management system, and it has a weird quirk – there are no code files.

Oh, there’s code, but all templating is done from the interface inside a textarea (thankfully with syntax highlighting…). All configuration is done from the interface too. You configure your navigation elements and such in the interface, then in another window, you manage the HTML to output them.

(No, this is not Drupal. But Drupal does this too, and I also struggle with it there, as do a lot of other developers I know.)

The goal is that you don’t have to be a developer to work with it. But for a developer…this sucks. It really does. And it’s forced me to acknowledge something I intuitively knew to be true, but never articulated: files are the currency of web development.

From Wikipedia:

In economics, currency is a generally accepted medium of exchange.

A file is the “generally accepted medium of exchange” in development.

You codify work into a file, and it becomes the transport mechanism for that work. The file gets passed around to both human and machine. It is the wrapper – the envelope – that binds and protects a work product and allows it to be easily transported.

With a file, you can do the following:

• You can source control the files in Git (the CMS we’re struggling with doesn’t even version templates, which frankly scares the hell out of me; I envision a 3 a.m. call from their webmaster, right after he fat fingers the entire page layout template into oblivion)

• You can work with the files in a true IDE, with all the automation that allows

• You can implement an automated build process, a la Jenkins or CruiseControl

• You can diff the files when necessary (which is often…)

• You can put the files in a code review tool (like Crucible) for collaboration

• You can use things like AIDE as a security tool to check file integrity

• Anyone can work on the files, even if they haven’t been trained on the CMS (our visual designers, for instance)

Note that these are things you cannot do easily with a database record. Indeed, how do you transport a database record? I have no doubt you can come up with a way, but I also have no doubt that’s it’s a hell of a lot more complicated than copying a file somewhere and that no mainstream development tool integrates with it.

Here are two examples of where a file-based model clearly beats a data-based model –

In the blogging platform Movable Type – on which this blog ran for almost a decade – you could template in the interface as well, but with one crucial difference: you could link any template to a file. You could specify a file on the file system, link a template to it, then it would sync against that file. When you saved from the interface, it would save into the file, and when it needed the code from this template (when rendering), it would read it from this file.

This is an extremely simple feature, but very powerful. I had many templates which I managed from the file system, and some other (smaller) templates that I just changed in the interface. Sometimes I worked with both – if I had a small change, I did it from the interface, then used the file and an IDE (EditPlus) from my desktop for larger changes.

What was great is that you lost nothing. This simple system kept both sides happy. You could use either method, without detracting from the other.

By default in Episerver, Page Types (content types, essentially) are configured from the interface. You create a new Page Type, then configure your properties and other details.

Sadly, this means you have to duplicate this process when moving Page Types between environments. You configure your new Page Type in development, then after you deploy all the code for it, you have to go re-configure that page type in production (quickly…).

(I had this problem with Ektron too. Build your new Smartform, export the XML, import in the new environment, repeat…)

Enter Page Type Builder, which is an open-source project that lets you configure Episerver Page Types as full-fledged classes in C#. It’s stated purpose is to let you work with content as strongly-typed objects in your code, but that’s not the real benefit, in my opinion. The real benefit is that moving Page Types between environments is trivial now.

When Episerver starts up, Page Type Builder syncs everything – it runs through the C# classes which represent your Page Types and makes the adjustments necessary to alter existing types and make new ones (it does not delete anything, as a rule).

This means that when I configure a big change in development, and deploy the code for it in the form of a file, the Page Type goes with it, and magically gets deployed as well. (Sure, this means that editors no longer create Page Types from the interface, but what is lost by this? Nothing. A new Page Types invariably means new templating code, at the very least, so you were always deploying something, no matter what.)

Not surprisingly, Page Type Builder has become de rigueur for any Episerver project. Also not surprising, Episerver has built code-based Page Types into their next version. (Also not surprising: developers love CMS vendors who listen to their network of developers…)

Files work. They are the currency of web development. They are the thing we use to encapsulate our work and transport it. If your CMS doesn’t use files, you have lost a significant chunk of associated functionality, and in the process have alienated a large segment of developers.