Play framework

Excellent! This is how java web frameworks should had been from 2005. Play is a full stack framework and has so many features that putting them all on this post it will end up being an index list. But it’s not only the long list of features it has, it’s that everything works out of the box, there is no need to figure out how to do something. As I said the list is big, so I will only list those that I found more exciting… (I am using this framework on one of my current projects and it works very well on production environment, it’s not just another experiment).

Here they are:

  • Active Record style model, based on JPA annotations and backed by hibernate. This is probably the most missing feature form java frameworks, for some strange reason no other Java web framework (at least non that I am aware off) tackle this one and developers are stack with an anemic model – well this is probably a very controversial issue with pros and cons from both sides, anyway, this works fine for me and the fact that it removes the need for DAOs is a big win. Furthermore, just like POJOs you can transfer the model objects them from the service layer to the front-end and back again.
  • No need to compile the sources, just make a change and reload your browser.
  • Template engine, it uses Groovy as an expression language, I am not familiar with Groovy at all but I love this feature, it works just like the django templates, there is no need to know Groovy to use it.
  • Play is modular, there are already plenty of modules to use and it’s really easy to write yours. Standard distribution of Play comes with two optional modules, CRUD and Secure. I think all projects have a need for both modules. With CRUD you have a full web administration interface for all your model objects and it’s fully customizable. Secure is a simple module that helps you setup a basic authentication and authorization management, it’s also highly customizable.
  • Play also ships with an embedded application server, just type ”play run” and the world is ready for your next cool app, of course you can deploy your application on any application server. It’s really nice that the embedded application server is ready for production, it’s not just a subset to help you during development.
  • Testing the app is easier than ever.  It uses the JUnit for unit and functional testing, in your functional testing you can access directly your web controller objects. And there is a third kind of testing, Selenium for your views. But it does not stop there you can run your tests from your web page. In fact the tests are loaded only when you run Play in test mode “play test CoolApp”. Even more, with the Fixtures help class you can load your test data from a yaml file in no time. Do you want more! Continuous Integration to run your test auto-magically, just run Play with the auto-test command. I know what you think, you can do all these with any framework since they are not framework specific, but just imagine the time you need to set everything up, in Play they just work.
  • Ready for REST, it is easily scaled by running multiple instances of the same application on several servers.
  • IDE agnostic :) it comes with a command line tool that converts your project so it can be used in your favorite IDE.
  • And it’s really fast

There are a lot more cool things about this framework. It’s very different from the rest of the frameworks in a good way, just as Spring broke the rules of enterprise development years ago, Play does the same, it breaks the rules and takes an unconventional away of doing thing which is closer to the developer, with the usability and productivity in mind.

Give it a try

django template tag for active CSS class

Navigation bar is an important part of the web application since it is the map that guides the users in different parts of the application. For better user experience navigation bars should indication which option is currently selected by the user. A common way to indicate which option is selected is by simply changing the CSS style of the selected option.

Vincent Foley has a very good article in his blog of how to implement a navigation bar in django. I include the latest paragraph of his post here, so if you are not familiar with url patterns and django template tags please read the full article of Vincent:

def active(request, pattern):
    import re
    if, request.path):
        return 'active'
    return ''

<!-- navigation -->

{% load tags %}
<div id="navigation">
    <a class="{% active request "^/$" %}" href="/">Home</a>
    <a class="{% active request "^/services/" %}" href="/services/">Services</a>
    <a class="{% active request "^/contact/" %}" href="/contact/">Contact</a>

This is a pretty good implementation but from my point of view it has one problem. It binds the url patterns with the template page. If you need to change the url pattern you must not forget to change the template also. Furthermore, what happens if you ship the application and the client decides to change the urls of the application.

Fortunately django has two features that allows to push this implementation one step further.
The first feature is that in django we can name the the url patterns, so the will look something like this:

urlpatterns += patterns('',
(r'/$', view_home_method, 'home_url_name'),
(r'/services/$', view_services_method, 'services_url_name'),
(r'/contact/$', view_contact_method, 'contact_url_name'),

The second feature is that we can create variables in the template page, the following code creates three variables (home, services and contact) these variables holds the url patterns for the respective names:

{% url home_url_name as home %}
{% url services_url_name as services %}
{% url contact_url_name as contact %}

Combining these two features of django we can modify the code of Vincent as follows:

{% load tags %}

{% url home_url_name as home %}
{% url services_url_name as services %}
{% url contact_url_name as contact %}

<div id="navigation">
    <a class="{% active request home %}" href="home">Home</a>
    <a class="{% active request services %}" href="services">Services</a>
    <a class="{% active request contact %}" href="contact">Contact</a>

As you can see we have totally decoupled the url patters from the template page. I know we have coupled it with the url names but there are no reasons whatsoever to change the url names since they are not visible anywhere, from now on we can change the url patterns as we wish.
Also note that the href tag has changed to the new variable that we created so it points to the correct url.

Important: There is not need to change the template tag.