INI Files are a well-known format that might work well for marking up a form based applications. It turns out they are less than perfect, but I developed something a month ago for a “menu” application, and thought I’d link to it for a quick blog entry. Here’s a video that talks through it:

ini files as templates from Paul Hammant on Vimeo.

Here’s the github project

Pros and cons

INI files have sections, keys and properties. I made a menu for a restaurant, and it worked OK for that. INI files must have unique keys though, but there’s no easy mechanism to enforce uniqueness. I could make an online editor for a menu in INI format, but I’d have to write some validation logic for uniqueness that’s triggered when the user attempts to save it. I’d also have to make sure that all keys have values, and that sections are marked up correctly. It wouldn’t be a polished editing environment (like Wufoo) but it would be editable by users with training.

Sophisticated validation might be cumbersome to markup too:

mains1.title = Tikka Masala
mains1.desc = A tomato and cream sauce flavored with fenugreek.
mains1.options = Hot \| *Medium \| Mild

Anyway, my big plus here is that changes to an INI file are very mergable, and my readers should know by now that I’m very keen on source-control as a backing store for certain categories of things.

On balance though, markdown with some rudimentary codes inline for the fields, might have been better. Nobody say HTML though - it hurts end-users eyes and that’s what I’m aiming at here (end-users and not hurting their eyes).

My coding choices

I’m doing server-side templating AND client side MVC. The server-side is 45 lines of Python with Bottle and Bottle’s own templates. It is processing the INI files into a thing that looks like a full menu in HTML. On the client side it is Angular (12 lines of JavaScript), and all it is doing is binding the menu choices to an object tree thing, and binding that Firebase object. Just think of that last as a live JSON object, in a cloud database. You might prefer pushing the JSON back to the Python server, and it wouldn’t be a lot of code to implement that. Twelve lines of code. I’m ignoring Angular’s established standards, and inlining all the JavaScript. It’s much more teachable that way. If you wanted to fill CDNs to serve 10K+ concurrently connected guest-users, you’d not do it this way. You’d decompose as the AngularJS community says you should.

There’s a small snafu with server side and client side templating with {᠎{ “handlebars” }᠎} in that both systems want to act on it. As the server-side templating is first, let it win, and utilize Angular’s as ngBind instead (if you need that). Alternatively mark {᠎{ as a variable in the server-side template grammar and insert it where you need double-curly-left-bracket, etc.