Fun stuff

Getting Started with the Play Framework

Alex Hanschke

What makes Play so special? In the first of a two part series, find out how you can tap into the latest trends with this innovative framework.

A brief introduction for Java Developers

These days, it’s hard to imagine a world without the Internet. Today’s applications are becoming increasingly connected; mash-ups of several services are becoming the norm. You have to wonder – where will we be in ten years?

If you’re reading this, chances are that you’re already familiar with the Java ecosystem. And with such a wide variety of web frameworks to choose from, why would you want to get to know yet another one? What it is about Play that makes it so special?

Why Play?

Play taps into current trends like cloud and big data. It fosters a stateless architecture and is RESTful by design. Developers can start implementing their applications with Play immediately: just save the code, hit refresh and you see all changes within a matter of seconds. Compare that to excessive application servers which you frequently have to restart before you can see your changes. Play comes with support for all major IDEs, although all you need is a simple text editor. Another major benefit is its type safety, which you won’t just notice in your controllers and models, but even in your views and routes! And if you’re a fan of LESS and CoffeeScript, you can make use of both directly in Play, which comes with a built-in compiler for both.

It’s easy to distinguish between component-based web frameworks like JSF or Vaadin and request-response-oriented frameworks such as the Play Framework (Play). While component-based variants try to hide everything that happens under the hood, request-response-based frameworks work much more closely with the HTTP protocol. And that means they give the developer several advantages which are lacking in component-based frameworks.

If you have a Java EE background, you will be amazed how much more productive you can be by using Play. You can easily kick off an application within a matter of seconds. This productivity gain makes it a natural choice for rapid prototyping, but it also makes a full-fledged solution for large-scale enterprise applications.

Ye Olde Bookstore

To discuss the features of Play in a broader context, let’s take a look at a sample application.

Most web frameworks will help you get your application up and running quickly. Render an input field, enter some data and submit it to the server, process it and render something back. It is the Hello World! for web frameworks. But that’s not quite what we want to do with Play. We want to see if this technology can fulfil our requirements.

When it starts getting more complex (think of validating a submitted password with the corresponding confirmation), things can easily get messy. And that’s only one of many examples. That’s why we’re not just going to get to know the framework, but we’ll also take a look at some of the common use cases and how to approach them with Play. You want to route a user back to the page they came from after a login? No problem. Store your data in the cloud? We’ll cover that too.

The example that we’ll be using is a bookstore. In order to keep things simple, we won’t make use of multiple features, such as shopping carts. Nevertheless, Play can easily support these use cases and once you get started you should be able to implement them on your own.


To get up and running, you’ll need to download the latest version of Play (2.1.0 when this was written) directly from the project site:

Unpack the contents to a directory of your choice. Once this is completed, you should add the executable to your operating systems’ path variable, which under Mac OS can be achieved as follows:

$ export PATH=$PATH:/your/path/to/play-2.1.0

Listing 1.1 Adding the Play executable to your path on Mac OS

Now let’s see if everything works as expected by submitting play help in a shell. You should see a welcome message similar to the one shown in image 1.1.

Image 1.1 Welcome to Play!

Creating our first project

Now we’re ready to create our sample application. Choose a directory where you want the project to be located and then create it by running play new play-bookstore.

We confirm the name of the project by hitting [ENTER] and choose to create a simple Java application when asked. That’s it! Play has already generated a skeleton bookstore for us, so let’s have a look at what has been created.

Image 1.2 Bookstore project structure

During initialization Play already created all the directories we need. The resulting structure should look similar to the one shown in image 1.2. Let’s briefly walk through the directories one by one to see what they are good for.

The app directory contains our source files, such as controllers, the domain models and our views. In conf we can find the main application configuration and a file named routes. These routes describe the endpoints provided by our application in terms of URIs whereas each route is wired to a specific controller. Dependencies on other libraries and plugins are managed in the project directory. In Build.scala we can declare each dependency using Scala syntax. You should be able to grasp the structure even without prior Scala knowledge. Our public assets are served from the public directory. Here we keep stylesheets, JavaScripts and images. Play comes with native support for LESS CSS ( and CoffeeScript ( So we will find the corresponding files here as well. Last but not least the test directory keeps track of our tests of all kind, such as unit and integration tests.

Enough said – let’s run it!

What Play has created is executable through play run. Play compiles all of the code and starts up a Netty server, which serves our bookstore. When we run Play like this, it is started in development mode, meaning Play will wait for an initial request before starting the application, as opposed to the production mode where the application is started immediately. So go ahead and open http://localhost:9000 in your browser and you should see a screen similar to the one shown in image 1.3.

Image 1.3 Your new application is ready

If you can’t bind the server to the default port 9000, you can also specify an alternative port by passing it as an argument: play “run 8080” (mind the quotes).

Request lifecycle

Before we dig any deeper, here’s what happened when you opened the application in your browser:

  1. Your browser requested the resource under “/” – the application root.

  2. Play figured out the handler for this request by looking up the aforementioned routes file.

  3. The action to invoke is called index and it is defined by a controller named Application.

  4. In index, the view to be rendered is chosen and sent back to your browser.

  5. The view you eventually saw is defined in a file named index.scala.html.

While the application is running, we can now change some values, hit reload and see the browser picking up on these changes immediately.

Open the Application class located under app/controllers. In the index method, change the text to another value, save your changes and refresh the page in the browser. You should now see the new value. As you can see, Play recompiles your application on the fly whenever it detects changes.

The basics of HTTP

When working with web frameworks it is helpful if you are familiar with the basics of the Hypertext Transfer Protocol (HTTP). While there are plenty of frameworks in the Java ecosystem that do their best to hide the low-level HTTP operations behind a component-based API, Play follows a request-response-based approach, similar to how Servlets work.

HTTP supports a couple of verbs, four of which are of major interest when working with Play. They are GET, POST, UPDATE and DELETE. When you open a particular address in your browser, say, the browser performs a GET request, i.e. it requests to read data from the server. POST is used whenever we request the creation of a new resource on the server under the corresponding URI. For example, this is the case when we want to create a new book based on the input provided by a user. Likewise, the two remaining verbs are used to update existing resources on the server, or to delete them respectively.

RESTful design

Building directly on HTTP, REpresentational State Transfer (REST) follows the idea that everything in an application can be exported as a resource. Resources can be read, manipulated and deleted using pure HTTP. Furthermore, resources can be represented in arbitrary formats. For example, a book resource can be represented as an HTML page or in JSON. Play encourages the use of RESTful design, so this is what it might look like in your application:

GET /books

GET /books/1234.xml

POST /books

Listing 1.2 Defining URIs to access book resources

The first request attempts to read a collection of book resources, whereas the second request reads a specific book resource represented in XML. The last request can be used to create a new book resource with the content submitted with the request.

Depending on the Accept header in our request, we can request a particular representation from the server. For example with Accept: application/xml we specify that we want to read the XML representation of a resource. A client can specify several representations as a fallback mechanism for the server, a process which is also referred to as content negotiation.

Thus, a resource can have multiple representations in a RESTful application.

Apart from the welcome page you have just seen, Play also deploys an offline documentation, which is accessible at http://localhost:9000/@documentation while the server is running. This is pretty handy if you are developing offline and need to access the documentation or the JavaDocs.

Preparing the editor

Now it’s time to get our feet wet and start developing, so let’s choose an appropriate editor and have a look at the development workflow.

Play supports all major IDEs, but you might as well go for a simple text editor such as Sublime Text 2 ( for development. However, as it is so widely adopted, we will use Eclipse. To create the required project files, open a shell in your actual project root and run play eclipse.

In Eclipse, choose File | Import… | Existing projects into workspace, browse to your project directory and confirm the import. Play expects all files to be encoded as UTF-8 so whatever tool you choose for development, make sure that UTF-8 encoding is the default. Eclipse usually has this set already, but you can verify it by checking that Text File Encoding is properly set under Project | Properties | Resource.

Well done! Now you’re ready to dive straight into the development!

This is an excerpt from the forthcoming Developer.Press title Getting Started with Play. In the next chapter of the book, Alex walks us through the domain model and the persistence layer.

About the author

Alexander Hanschke holds a Master’s in Business Informatics from the University of Mannheim. While graduating, he joined the Karlsruhe-based consultancy COINOR AG where he helped customers from the financial sector build large-scale enterprise applications using Java EE. After working with COINOR for two years, Alex decided to step out and build his own company, techdev Solutions. He now helps clients across all industries build cloud-enabled applications. He has been developing applications in the Play Framework for two years and recently spoke on this topic at a JAX Conference.

Inline Feedbacks
View all comments