Tag: scala

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")

▸

Posted in Scala & Playframwork 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()

▸

Posted in Scala & Playframwork 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)

▸

Posted in Scala & Playframwork Tagged with: , ,

Play 2.0, Scala and the new way of doing things

Recently there’s been a (heated) discussion on the Play framework mailing list about Play 1.x vs Play 2.0, Scala, and the added level of complexity.

First off, some of these points are completely valid. For many Java hackers, Play 1.x was an enlightenment. While it’s true that it was a copy of Ruby on Rails in Java, it was the first framework which allowed agile web development on the JVM (i.e. hot-reloading, compile errors are shown in the browser, no XML configuration, and so on). With 1.1 and 1.2 it added most of the needed features while keeping a light style of development. Many people feel that with Play 2.0, this lightness has gone.

Why is that? Let me show you some examples.

Claim 1: You have to learn a new language

Play 2.0 is written in Scala, and even though it has a Java API, as a non-Scala developer you quickly encounter code you don’t understand. First and foremost, it’s the templating engine, which is based on Scala. The framework authors’ response is that you can switch out the templating engine. But why use a web framework if you have to switch out every component? And it’s obviously not the first thing you want to do when trying out something for the first time. I still don’t understand why they didn’t bundle the Groovy engine.

The build file is not only written in Scala, but even a Scala DSL. I initially found this to be an advantage since I already knew SBT. Well, at least I thought so. SBT 0.7 was a joy to use, but apparently it’s a fun exercise to completely change the DSL with every point-release. They should also have changed the name because this tool is anything but simple.

And for the record, the route files are written in Scala-style, too. However, this shouldn’t be a big a deal, as the route syntax is pretty limited.

Whether or not you like Scala itself is a very personal choice; you should at least give it a try. Yes it’s a complex beast, but it also allows you to write beautiful code, especially if you embrace the functional paradigm (see the examples below).

Claim 2: Compilation times are slower

This is what I found to be the biggest problem with Play 2.0. Agile development with fast tournaround times makes only half as much sense when one small change in a templates results in the recompilation of 60 classes and takes 10 seconds. Fortunately, the authors of Play and of SBT (the compiler being the main culprit here) are aware of that. So hopefully, compile times will improve in the near future.

Another annoyance was unexpected runtime errors (e.g. VerifyError) every now and then. This should vanish as the framework matures.


So, is Play 2.0 a step in the wrong direction? Absolutely not. I used Play 2.0 with Scala for about three months (even before it reached RC status), and found it an an absolute joy to use. In short, this is because it supports a style of development I’d call Functional Web Programming. Let me show you what I mean by that.

Action Composition

Actions (i.e. the methods that are invoked by clicking a link or pushing a button) are composable, which means you can take one, and wrap it around another, and end up with a new action that is a combination of the two. This allows for powerful and scaling abstractions.

The basic action is called Action (no surprise here) and is essentially a function which maps a request to a result. For example, in our application we have pages that can only be accessed by an administrator. So the easiest way to protect those pages was to define an action called AuthenticatedAdmin which in turns calls Authenticated (whose only job is it to verify if the user is logged in), which in turn calls the actual action.

In terms of code it looks like this:

def Authenticated[A](p: BodyParser[A])(f: AuthenticatedRequest[A] => Result) = {
  Action(p) { implicit request =>
    request.session.get("email").flatMap(email => UserDAO.findByEmail(email)).map { user =>
      f(AuthenticatedRequest(user, request))
    }.getOrElse(Results.Ok(views.html.error("Not Authorized", "You have to log in to view the requested page")))

def AuthenticatedAdmin[A](f: AuthenticatedRequest[AnyContent] => Result) = Authenticated { implicit request =>
  request.user.adminProfile match {
    case Some(profile: AdminProfile) => f(AuthenticatedRequest(request.user, request))
    case _ => Results.Ok(views.html.error("Not Authorized", "You need administrator privileges to access the requested page"))

▸

Posted in Scala & Playframwork Tagged with: , ,