Having used Django (and other python web frameworks) on and off for three years, I came across the Play framework some time ago. However, it’s only recently that I’ve been able to use it for for a project. Note that this post is written from a Django developer’s perspective, but I’m not attempting a “Django vs Play” type of comparison. Instead, the following notes how a Django developer might approach the framework and map their own experience to it.
Play looks great for a number of reasons: it’s simple to set up, has a wide range of libraries and plugins that come out of the box, and has an active community surrounding it.
Initial Project Setup
Project setup is simple, and generates the necessary files and directory structure.
1
|
|
Replaces the familiar startproject
command.
A range of libraries are already packaged with Play, including Joda Time, google-gson, Log4j, test runners, and database connectors. “Convention over configuration” is often cited as one of Play’s aims.
IDE Support
Creating an Eclipse project configuration for your project happens through the eclipsify
command. Pydev, on the other hand, requires some manual setup, particularly if you are using different interpreters with vitualenv
. Though simple, this can become tedious. And of course, static analysis capability is likely to differ signficantly because of the different type systems, but that’s a discussion outside the scope of this article.
Although this is not directly related to IDE support, it’s also worth mentioning that both frameworks support automatic application reloading based on file changes.
Model Declaration
Play exposes its own JPA (Java Persistence API) interface. The entity manager is already configured and can be easily accessed (e.g. for transactions).
1 2 3 4 5 6 7 8 9 |
|
As you can see, model declaration is concise, though the OO Architect in you might be shouting about encapsulation. Models are accessed directly through model.attribute
, but getters and setters are automatically generated and used for access. These can be easily overridden. As a python developer, you might already be missing descriptors and the @property
annotation!
A pre-configured entity manager is provided, but can easily be adjusted. In fact, my first application used an exisiting database, so I needed to declare models but disable DDL generation. This was easily done in application.conf
.
Templating
Generally, Play’s templating engine can be described as similar to Django’s.
One nice feature is the %{ }%
(script) tag that allows you to write scripts (with variable assignment, etc.) Of course, you don’t want to be doing any heavy lifting in the templates, but it can be very useful, e.g.:
1 2 3 4 5 |
|
Java object extensions (methods added to an object when used in a template) are another useful feature. To take the example from the documentation, the format
method applied to Java.lang.Number
gives the formatted result:
1
|
|
See the play template documentation for more details on these and more.
Test Framework Integration
Both Django and Play feature excellent test framework integration. Play has integrated the selenium test framework, and also allows tests to be run from the browser, a very handy feature.
Selenium support will ship in Django 1.4, but is not currently available.
Admin Interface
A great help in Django development is the admin interface. While it requires a little more setup, the CRUD module in Play gives a simple browser-based way of managing entities.
See more in the CRUD documentation.
Conclusion
Both frameworks have many strengths, and it is encouraging to see highly active development in both. There are a few features in Play which might make a Django developer envious, such as modules for OAuth/OAuth2 authentication and websockets built in. However, the frameworks are certainly very evenly matched.