So after 2 posts of build up I missed my last posting slot, sorry about that. Hopefully this will get things back on track. What I’m planning to cover in this post is the architecture we chose for our tools, and some of the technologies involved.
The BlitzTech toolchain has been in development for over a decade now, so from the outset of creating any web based user interfaces we knew that throwing it away and starting again wasn’t an option – we would have to bolt any new features onto the existing codebase, enhancing or replacing systems one at a time. In fact it’s probably worth noting that there was never a single point where we said “Hey, let’s rewrite the tools using a web UI, that’ll be amazing!”, it was always “Here’s a problem we’ve got, how can we solve it?” or “If we try this, what will benefits will it bring?”.
Jumping back several years, the first question we posed was “We want to add a pretty home-screen to the tools, how can we do that?”. At the time we went for an embedded Internet Explorer window which we loaded HTML text directly into. Over time web controls popped up in other parts of the tool, but for a long while there was no real architecture in place, we just generated lumps of HTML and served them up, and it was all pretty static.
Fast forward a couple of years and another question was posed: “Our custom scripting language for the tools isn’t giving us the power we need, what should we replace it with?”. At this point the idea of web-based user interface wasn’t even considered, we were just looking for a decent scripting language. After a bit of debate we chose Python, which in hindsight was rather fortuitous since it has a good set of web related libraries, and set about building a scripting API rather like you would find in something like Maya.
A few months after that came the question “Generating and loading HTML directly seems pretty clunky, and it makes linking between pages really awkward. How can we solve these problems?”. This is the point where a true web-app framework started to emerge. First off, we added a HTTP server to the tool which meant we could serve up text, pictures, etc. using standard URLs. We chose to write our own HTTP server, partly because it looked as easy to do that as integrate an off-the-shelf product, but also just so we had full control over it. As it turns out, it’s not quite as simple as it appears – the HTTP protocol has various oddities that need to be handled – but the flexibility has come in useful.
Shortly after that came the next big step forward – we discovered the Web Server Gateway Interface (Django (a popular Python web framework) within our HTTP server, and because it’s running within the tool, we could use our Python scripting API to generate page content and perform operations based on the data in the editor.
Currently we’re not using Django directly, but are using some of the same libraries that Django uses or similar alternatives. The two main ones are Jinja, a template expansion library that we use to render our HTML templates.
One of the most recent changes to our set-up was ditching the embedded Internet Explorer window control in favour of Chromium. This was done to solve various compatibility issues – we’d found that some machines had old versions of IE installed which couldn’t render our pages properly, and even the newer versions of IE were lacking in support for CSS3 and HTML5 features that we wanted to utilise.
That sums up most of the key components, so perhaps now is a good time to show a diagram:
I’ve colour coded the custom written parts in green, the open source projects that we’ve used in blue, and the pre-existing Blitztech tools code in purple. You can see that the tools code (containing all the data and logic for world editing, etc.) only talks to the page handlers, and that the browser (either the embedded browser panels with our tool, or a stand-alone browser) only talks to the HTTP server. Having these clear boundaries in place is great for enforcing good design.
I hope this post has given you some insight into the web-app system we’ve created. Next time I’ll delve further into specifics in a few areas, refer back to the pros and cons from my last post and try to give some real world examples.