O2 and I are at it again – this time with a mixture of python, xslt and erlang soup’n up to provide what will be the best and best value e-marketting tool around. The python part is that our shop window is written in django, with lots of jQuery magic providing a slick UI. I’m particularly fond of jQuery and my favoured style of web development is to implement the back-end as a RESTful web service and then consume and decorate this web exposure with a dynamic UI. The reason behind django (as opposed to one of the millions of other web frameworks) is that we both know python inside out. And I get plenty of ruby hacking done both at work (where we are near OCD about capistrano) and in developing much of axiom.

So where does the erlang part come in? Well that’s not all up for public consumption, but suffice to say there is a fair chunk of what we’re planning to do which is what I would call “infrastructure programming” and that is something that erlang is basically perfect for. Not least of what we need is a distributed, fault tolerant grid without spending much money either building or hosting the thing, and again, we’re on to the right tool for the job.

Some of what we’ll be doing involves handling http requests, and for that, I’m currently in favour of using either mochiweb or yaws. For our needs, the former is a simpler choice but one thing that mochiweb doesn’t provide out of the box is a way to map requests to the appropriate chunk of request handling code. Our latest open source forray aims to add this capability, albeit in a way that isn’t specifically tied to mochiweb.

Enter urlconf-erlang. There’s no link because the source code still lives in a private repo and we’re not ready to release it yet. 🙂

Inspired by someone’s laudible effort to implement the django templating language in erlang, we decided to implement something akin to django’s url mapping system for our own evil purposes. Our current implementation only really deals with a single layer of mappings and does so by simply matching the url against a regex and returning the MFA (Module, Function, Args) configured against it. A quick peek at one of the test cases should make this a bit clearer:

named_arguments_supported_by_regex_impl(_) ->
    Path = "/users/fwnext-retail/billing-address",
    Rx = "/users/(?.*)/(?.*)$",
    Config = {
        httpd.urlconf.regex,
        [{Rx, my.controllers.users, {
            my_user_function,
            [uname, subcomponent]
        }}]
    },
    server:start(Config),
    expect_that(
        server:lookup_dispatcher(Path),
        matches(
            {mfa, {
            my.controllers.users,
            my_user_function,
            [
                {uname, "fwnext-retail"},
                {subcomponent, "billing-address"}
            ]
        }})
    ).

As you can see there is some cruft because none of the Erlang regex libraries support named capture groups particularly well. In addition to this, we’re using the .re top level module (which is still not officially supported in R12B) as it is the only implementation we’ve found that is both fast and reliable. Because the choice of regex ibrary is likely to be a contentious point, we’ve taken the step of making the urlconf server a parameterized module, allowing you to pass in your own regex implementation instead of ours.