Experiments with Play! Framework

As I wrote in my last post, I recently rewrote one of my hobby projects from ASP.NET MVC to Play! Framework. Play! was very easy to get started with, the only thing required was to have a JDK installed and to download the zip distribution of Play, unzip it to a directory and fire it up using the Play console. Play comes bundled with the Netty http server which can be used for both development and production use. Play is a MVC framework, much in style with ASP.NET MVC. I am not going to go into detail to describe how it works or its features, there is already plenty of articles about it out there, instead I want to touch a few things I think is required from a framework to be productive.

IDE Support
It was quite easy to generate a project for Intellij IDEA was very easy using the Play console. Just type “idea” in the console (or “eclipseify” if you prefer Eclipse). One thing to remember is that everytime you add a new dependency to the project (in Build.scala) you need to rerun the “idea” command, otherwise IDEA will not find the packages and you will not be able to compile from within the IDE.

Support for testing
Play comes with built in support for integration testing (writing tests that test the entire application stack, controller to database). The tests can easily be run from the Play console, but running them from within IDEA turned out to be tricky. Running regular unittests in the project that does not use the in memory database run just fine from the IDE, but i have not been able to configure IDEA to setup the fake application context needed to run the integration tests. It seems like this issue have been brought up by the Play community several times, but no one seems to have an answer.

Dependency injection
Play! doesn’t have any prefered way of doing DI, so it is up to you to use the DI container of your choice. It turnes out that there is a Play plugin for Google Guice so getting started with Guice was easy.

This is what my Guice bootstrap looks like:

public class Dependencies implements Module {

    public void configure(Binder binder) {
        binder.bind(new TypeLiteral>(){}).to(RabbitMqQueue.class);
        binder.bind(ISubscriberHandler.class).to(SubscriberHandler.class);
        binder.bind(IEmailHandler.class).to(EmailHandler.class);
        binder.bind(ISubscriberHandler.class).to(SubscriberHandler.class);
        binder.bind(ISendAccountHandler.class).to(SendAccountHandler.class);
        binder.bind(ISettingsReader.class).to(SettingsReader.class);
        binder.bind(IGeoLocationHandler.class).to(GeoLocationHandler.class);
        binder.bind(ISmtpHandler.class).to(SmtpHandler.class);
    }
}

In Play controllers are static. The reasoning is that controllers should have no state and therefor should be static. In some way this makes sense, controllers should not keep a state, but it also limits us to property based injection instead of constructor based injection. To use dependency injection in the controllers we annotate the properties like this:

public class Emails extends Controller {

    @Inject
    public static EmailQueueHandler emailQueueHandler;

    @Inject
    public static ISmtpHandler smtpHandler;

    @Inject
    public static ISettingsReader settingsReader;

...

HTML Templating
Why do I mention the templating? It turnes out that Play is using a new Scala based templating engine that is heavily inspired by the ASP.NET Razor view engine, witch is the best view engine that I have used. In general the Scala view engine is great, the only complaint that I have is that the error messages can be very cryptic when something doesn’t compile.

Deployment
The preferred way of deploying Play is by using the built in web server and a proxy, such as Nginx in front of it to serve static files. This is how I have deployed my application. However, there is support for packaging a war file and deploying it to an application server such as Tomcat, the downside is that you lose some functionality. I think this is something that Play need to improve to become more enterprise friendly.

Conclusion
Without any previous knowledge of Play framework I was able to rewrite my application from ASP.NET to Play! in less than a week. I also took the opportunity to rewrite a lot of parts of the application that I have been wanting to do for a long time and switched html/css framework from Blueprint to Twitter Bootstrap. So overall I’m quite happy with Play.