Tag: java

Playframework Routes – Part 2, Advanced Use Cases

Play Routes – Part 2, Advanced Use Cases

Localized routes

There are different approaches to managing the user’s locale in a multi-language site. If most of the content is only available after log-in, a cookie backed by an entry in the User table should be enough. On your landing page you check for the Accept-Language header or check the IP address. Just make sure that Google Bot can index all publicly visible pages.

On content-heavy sites, one Google-compatible approach is to define the language in the URL. The first component of the URL should be the language (or, if really needed, both language and country). Using the first part of the URL not only to make it easier to differentiate for the user but also to makes it easier to manage the site in Webmaster Tools.

We have two options here. Either we define a regex, or we hard-code our supported languages. The second approach must be chosen when we optimize for Google (see section below).

# Map to language via RegEx /$language< [a-z]{2}>/videos/:id controllers.Video.showVideo(id: Long, language: String) # Hard-code supported languages /de/videos/:id controllers.Video.showVideo(id: Long, language = "de") /en/videos/:id controllers.Video.showVideo(id: Long, language = "en") ▸ Read more...

Tagged with: , ,

Playframework Routes – Part 1, Basics

Play Routes – Part 1, Basics

Routes? What’s to explain?

Routes in Play are not a difficult concept to grasp, but as always, the devil is in the details. Let me show you how to get the most out of routes and how to tackle some of the typical problems in designing the routing scheme of a Play web application.

Defining routes

Before we dive into the details, let’s recap the basics.

A route is a mapping from a URL to a controller action. Routes are defined in a Play project’s routes file in the conf folder. You can only use one routes file and routes in submodules are currently not supported (but will be in the upcoming 2.1 release).

A route is defined by specifying the HTTP method (Play supports GET, PUT, POST, DELETE), the path, and a fully-qualified controller method (usually called an action). These three elements are separated by as much whitespace as you like.

# Show the index page GET / controllers.Application.index() # Login POST /login controllers.Application.login() ▸ Read more...

Tagged with: , ,

Play Framework 2.0 Templates – Part 1, Parameters


Play Framework 2.0 includes a new and improved templating engine, based on Scala (also known as Twirl). When you don’t know Scala, this can be a bit of a hurdle to overcome. But instead of switching to a different engine, I invite you to learn the basics of Play Scala templating, as it is quite powerful and a joy to use.

What is a Template

A template is essentially a function, mapping its input values to either HTML, XML or any other text output. Everything is compiled and type-checked, that’s why you always have to declare all input parameters. Templates are files inside the views folder and use the naming convention <template-name>.scala.<format>. By default html, xml and txt are the supported formats.

The basic concept is based on ASP.NET Razor and uses the @-sign to mark occurrences of code that will be interpreted by the templating engine. To help the templating engine understand what is code and what is not, you can surround a line of code with @(). This is necessary when a white-space would indicate end of code. A full block of code can be defined with @{} – however this is something I try to avoid as much as possible because it indicates the view is doing the controller’s work.

Templates are rendered by the controller as a response to a request. For example, if you have a template app/views/users/profile.scala.html, you render it from your Java controller
like this:

return ok(views.html.users.profile.render());

Likewise, you can call it from other templates (never forget, it’s just a function):


For the rest of this article, I’m going to assume you have read (or at least skimmed) the templates articles from the Play wiki (Templates and Use Cases).


The first line of every template contains the parameter list(s). In Scala, you can define as many parameter lists as you like (we’ll see an application for that later on). Unlike Java, the type of a parameter comes after the name: <name>: <Type>. A simple template parameter list might look like this:

@(message: String)

Parameters can have default values and can be called by their name. Imagine you have a template that should either display a user’s data as text or as an edit form (depending on some logic elsewhere), you could include a boolean to indicate whether or not the object is editable for the current user. Since you don’t always want to explicitly pass the parameter, you can define a default:

@(user: User, isEditable: Boolean = false) ▸

Tagged with: , ,