Mastering play framework for scala: Leverage the awesome features of Play Framework to build scalable, resilient, and responsive applications

Let's start with the crucial part of the project—its build definition, and in our case, the build.sbt file. The .sbt extension comes from the build tool used for Play applications. We will go through the key concepts of this for anyone who isn't familiar with SBT. The build definition is essentially a list of keys and their corresponding values, more or less like assignment statements with the := symbol acting as the assignment operator.

The contents of the build file are:

name := "sampleApp"""

version := "1.0.0"

lazy val root = project.in(file(".")).enablePlugins(PlayScala)

In the preceding build definition, the values for the project's name, version, and root are specified. Another way of specifying values is by updating the existing ones. We can append to the existing values using the += symbol for individual items and ++= for sequences. For example:

resolvers += Resolver.sonatypeRepo("snapshots")

scalacOptions ++= Seq("-feature", "-language:reflectiveCalls")

resolvers is the list of URLs from where the dependencies can be picked up and scalacOptions is the list of parameters passed to the Scala compiler.

Alternatively, an SBT project can also use a .scala build file. The structure for our application would then be:

The .scala build definition for SimpleApp will be:

import sbt._
import Keys._
import play.Play.autoImport._
import PlayKeys._

object ApplicationBuild extends Build {

  val appName = "SimpleApp"
  val appVersion = "1.0.0"


  val appDependencies = Seq(
    // Add your project dependencies here
  )

  val main = Project(appName, file(".")).enablePlugins(play.PlayScala).settings(
    version := appVersion,
    libraryDependencies ++= appDependencies
  )

}

The .scala build definition comes in handy when we need to define custom tasks/settings for our application/plugin, since it uses Scala code. The .sbt definition is generally smaller and simpler than its corresponding .scala definition and is hence, more preferred.

Without the Play settings, which are imported by enabling the PlayScala plugin, SBT is clueless that our project is a Play application and is defined according to the semantics of a Play application.

So, is that statement sufficient for SBT to run a Play app correctly?

No, there is something else as well! SBT allows us to extend build definitions using plugins. Play-based projects make use of the Play SBT plugin and it is from this plugin that SBT gets the required settings. In order for SBT to download all the plugins that our project will be using, they should be added explicitly. This is done by adding them in plugins.sbt in the projectRoot/project directory.

Let's take a look at the plugins.sbt file. The file content will be:

resolvers += "Typesafe repository" at "http://repo.typesafe.com/typesafe/releases/"

addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.3.8")

The parameter passed to addSbtPlugin is the Ivy module ID for the plugin. The resolver is helpful when the plugin is not hosted on Maven or Typesafe repositories.

The build.properties file is used to specify the SBT version to avoid incompatibility issues between the same build definitions compiled by using two or more different versions of SBT.

This covers all the build-related files of a Play application.

Now, let us look at the source code for our project. Most of the source is in the app folder. Generally, the model's code is within app/models or app/com/projectName/models and the controller's source code is in app/co ntrollers or app/com/projectName/controllers, where com.projectName is the package. The code for the views should be in app/views or within a subfolder in app/views.

The views/main.scala.html file is the page we will be able to see when we run our application. If this file is missing, you can add it. If you are wondering why the file is named main.scala.html and not main.html, this is because it's a Twirl template; it facilitates using Scala code along with HTML to define views. We will delve deeper into this in Chapter 4, Exploring Views.

Now, update the content of main.scala.html to:

@(title: String)(content: Html)

<!DOCTYPE html>

<html>
    <head>
        <title>@title</title>
    </head>
    <body>
    @content
    </body>
</html>

We can provide the title and content from our Scala code to display this view. A view can be bound to a specific request through the controllers. So, let's update the code for our controller SampleAppController, as follows:

package controllers

import play.api.mvc._
import play.api.templates.Html

object SampleAppController extends Controller {
  def index = Action {
    val content = Html("<div>This is the content for the sample app<div>")
        Ok(views.html.main("Home")(content))
  }
  }

Action and Ok are methods made available by the play.mvc.api package. Chapter 2, Defining Actions covers them in detail.

On saving the changes and running the application, we will see the page hosted at http://localhost:9000, as shown in the screenshot:

Let's see how the request was handled!

All requests that will be supported by the application must be defined in the conf/routes file. Each route definition has three parts. The first part is the request method. It can be any one of GET, POST, PUT, and DELETE. The second part is the path and the third is the method, which returns a response. When a request is defined in the conf/routes file, the method to which it is mapped in the conf/routes file is called.

For example, an entry in the routes file would be:

GET         /                        controllers.SampleAppController.index

This means that for a GET request on the / path, we have mapped the response to be the one returned from the SampleController.index() method.

A sample request would be:

curl 'http://localhost:9000/' 

Go ahead and add a few more pages to the application to get more comfortable, maybe a FAQ, Contact Us, or About.

The request-response cycle for a Play app, explained in the preceding code is represented here:

The public directory is essentially used to serve resources, such as stylesheets, JavaScript, and images that are independent of Play. To make these files accessible, the path to public is also added in routes by default:

GET         /assets/*file            controllers.Assets.at(path="/public", file)

We will see routes in detail in Chapter 3, Building Routes.

The file conf/application.conf is used to set application-level configuration properties.

The target directory is used by SBT for the files generated during compile, build, or other processes.