Open House Route Planner – an experiment with Silex, Twig, Eloquent and Backbone

London Open House is an annual event where buildings across the capital that are normally inaccessible are opened up for the public to explore. This year’s event runs from 20th – 21st September and I usually try to get to see a few different things over the two days to make the most of the opportunity.

The Open House website lists all the buildings and information and has a search facility, but frustratingly doesn’t offer a simple way to collect together a list of the buildings you might want to see and plot some kind of itinerary for the day. That being the case I thought I would use it as an opportunity to build a tiny web app to help me plan my weekend and learn some new technologies along the way.

You can see the current version here: Open House Route Planner
I won’t go into all the ins and outs of the build but here a few thoughts on the various technologies I used:


Silex is a PHP micro-framework based on the Symfony set of components. I really like the simplicity of the Silex approach. It gives just enough structure to get things going but it doesn’t tie you down to a particular way of working. Here’s the canonical example from their site to give you an idea:

$app = new Silex\Application();

$app->get('/hello/{name}', function($name) use($app) {
return 'Hello '.$app->escape($name);

It makes for very readable code and allowed me to prototype things quickly. Naturally, as the app gets more complex there are better ways to structure things, but I like being able to get a quick result without having to dig into a whole load of examples and documentation.

Silex Skeleton

A quick nod to Silex Skeleton which sets up a nicely-organised Composer-based project for Silex apps. You can simply type composer create-project fabpot/silex-skeleton new-app and you’re almost ready to go.

I had to tweak a couple of things (like adding an .htaccess file to push everything to the front controller) but otherwise it was a very useful base on which to build


Twig is a templating engine made by the same people as Silex and integrates nicely with it. I hadn’t used it directly before, although I had looked at using it in some WordPress projects. If uses the double braces (eg. {{ thing }}) convention familiar to anyone who has used Moustache, but unlike that engine, it allows for some logic with the templates and comes with quite a few built in filters and helpers to format data correctly.

My templates were fairly simple so I didn’t get to explore the full potential but it might make an appearance in future projects if it seems suitable.

Eloquent ORM

Now this is one area of the backend that took most of the time to set up. Naturally, I needed a basic database to store my buildings and routes in and I started looking at connecting Silex to a database of some kind. To make things a bit more interesting I thought instead of using a simple access layer I would make use of an ORM solution to abstract away the persistence layer making it more flexible in the future. Also it would give me another bit of technology to learn.

Doctrine seems to be the biggest player in the PHP ORM arena an and whilst it is certainly powerful, the learning curve looked like it would sap my limited time. Instead I opted for Eloquent ORM which is part of the Laravel PHP framework. It has a nice fluent interface and there is an adapter to connect it to Silex as a service.

That said, it still took me some time to get my head around setting up the database schema and establishing the relations between my tables so that I could use the ORM correctly. The documentation is ok and although it is a fairly popular project, a lot of the examples I found were (understandably) using the Laravel framework so I had to disentangle the nuggets of information that I needed to get things working.

In the end it would probably have been quicker to use a simple DBAL and write the SQL by hand for what I needed. Still, it was good to get a sense of what Eloquent is capable of for more complex projects.


One last thing I needed for the backend was a way to get the information about each building so that I could build my list. Goutte is a nice little web-scraping library that wraps a few other things (such as Guzzle) to make it easier to grab the page from the Open House site and extract the basic info I needed.

Note: naturally I cached the scraped pages heavily so that I wouldn’t end up hitting the Open House site itself more that was necessary – they are a charity after all.

Once all that was wired together I ended up with a very simple REST API that I could query to add and retrieve collections of buildings and render them to the front end. Talking of which…

Frontend: Bower, Backbone, HTML5 Sortable, Map Icons

Having built the backend I could then use a very small Backbone-based app on the front end to pull the data and render it as a list with accompanying map. I used this lightweight HTML5 Sortable jQuery Plugin to allow users to drag and drop buildings into whatever order they wanted.

I looked at a few options for rendering maps but in the end I went with the simple solution – Google Maps. The API is reasonably easy to use and had most of the features I needed. One wrinkle was that I needed to display numbered markers to show the sequence of building that the user was planning to visit. Unfortunately the Google Maps markers don’t have a simple way of achieving this, but luckily I came across these (map icons)[] which extend the standard marker and allow arbitrary text to overlay the icon.


So I’m pretty pleased with the outcome – it does what I wanted it to do and allows me to share a simple URL with friends to suggest a possible route for the weekend. There’s not much in the way of styling and I didn’t really bother to test it beyond the devices I am planning to use it on, but as a proof of concept I think it stands up.

One of the great things about modern web development is the availability of a huge range of well-written, open source libraries and frameworks that allows for exactly this kind of experiment at relatively short order.

Finally, it was nice to step outside of the WordPress development bubble for a while and expand and test my knowledge of the wider PHP landscape. PHP gets a lot of bad press, but frankly you can write good and bad software in any language and the main thing for me is to keep learning from all the great code that is out there and to use it to improve my own work.