In the previous post I discussed the need for a non-servlet based web development environment and introduced you to the Play framework. In this post, we’ll get started with Play and churn out some code.
Get started with Play
Typesafe gives us a reactive platform, Activator, for building Play applications. The platform helps you to create, build, test and deploy Play applications. In fact, it’s not only used for Play applications, but also for Scala, Akka or Java applications.
You can download Activator from https://typesafe.com/get-started. Installing activator gives you the set of files as shown in Figure 1.0.
Figure 1.0:Activator directory
You can add the activator-1.3.2 folder to the environment path. Open your Terminal or comand-prompt and enter activator new to create new projects. This command usually downloads a number of artifacts from the Maven repository. It will then, prompt your for creating new projects as shown in Figure 2.0.
Figure 2.0:activator new
As you notice in figure 2.0, there are different type of projects you can create in the platform. Let’s choose the 6th option, ie., play-scala and enter the project name as ‘HelloPlay’ as shown in figure 3.0.
Figure 3.0:Creating HelloPlay project
A directory HelloPlay is created with all the basic set of files and folders in it as shown in figure 4.0. Creating a Play project for the first time in your machine, may be a time consuming task depending on the internet speed, as a large number of dependent libraries are loaded from the Maven repository.
Figure 4.0:HelloPlay directory
The listing below gives you the description of the important files in our HelloPlay project.
- [app]- Contains the controllers, models and views. In other words it contains our application logic.
- build.sbt- The project build file. Here’s where we configure dependencies and other stuff.
- [conf]- The project configuration file application.conf and the routes configuration files are present.
- [public]- The JS, CSS and resources like the images are stored here.
- [test]- Contains the specs
Now, it’s time to run our application. Play framework comes with an embedded Netty server. Navigate to HelloPlay folder and enter activator run as shown in figure 5.0.
Figure 5.0:HelloPlay directory
The Netty server is started and running in port 9000 by default. You can launch your application from http://localhost:9000 to get the output shown in Figure 6.0.
Figure 6.0:Running HelloPlay
Let’s tweak HelloPlay
I am not going to dwelve deep into the code in this article. But the first lesson of learning anything new framework is incomplete, without the ‘Hello World‘. So let’s tweak our HelloPlay a little bit to display ‘Hello World’. In the app/controllers/Application.scala’ file, we have the Application controller class defined with an index method. The current default code looks as shown below.
package controllers
import play.api._
import play.api.mvc._
object Application extends Controller {
def index = Action {
Ok(views.html.index("Your new application is ready."))
}
}
The index method returns an Action. Action is a function that takes in an implicit request and returns a Result. Let’s create another method sayHello that prints Hello World as shown below.
...
object Application extends Controller {
def sayHello = Action {
Ok("Hello World")
}
def index = Action { ... }
}
The sayHello() method returns Ok(“Hello World”) that returns a result with plain text as output. Now how do we map http://localhost:9000 to sayHello() method? We have the routes. In the conf folder the routes has the mapping of requests with controller/actions. Currently you will notice the following mapping.
#Home page GET / controllers.Application.index
It’s pretty self-explanatory. Let’s comment this line and map / with controllers.Application.sayHello like this.
#Home page #GET / controllers.Application.index GET / controllers.Application.sayHello
Refreshing http://localhost:9000 in the browser will automatically recompile the files and produce the output as shown in figure 7.0.
Figure 7.0:Hello World
Instead of displaying ‘Hello World’ text, let’s create a view that will have the output. In the app/views folder you’ll notice some .scala.html files. Let’s ignore them for now and create a new file, say hello.scala.html with the following code.
<html>
<head>
<title>Hello World</title>
</head>
<body>
<h1>Hello World</h1>
<hr/>
</body>
</html>
Now, when you send a request to http://localhost:9000, show the above html file as a result. So, we modify the sayHello() method like this.
object Application extends Controller {
def sayHello = Action {
Ok(views.html.hello())
}
}
The views.html.hello() method invokes the hello.scala.html file. Internally the hello.scala.html file is compiled to a Scala object. For the adventurous, you can find these .class files in target/scala-2.11/classes/views/html folder. Refreshing http://localhost:9000 will give you the output as shown in figure 8.0.
Figure 8.0. Output with the html file
We’ve come this far! Let’s stretch it a bit more. We’ll pass a parameter say name to the sayHello method and display Hello
object Application extends Controller {
def sayHello(name:String) = Action {
Ok(views.html.hello(s"Hello $name"))
}
}
In the code above, the request parameters can be accepted as method arguments. The sayHello() method has the name parameter as an argument. We pass the message s(“Hello $name”) to the view file. Let’s modify our hello.scala.html file as shown below.
@(msg:String)
<html>
<head>
<title>Hello World</title>
</head>
<body>
<h1>@msg</h1>
<hr/>
</body>
</html>
Notice the special syntax @msg in the html file. We declare the @msg variable at the top and access it inside the <h1> element. The @msg variable holds the information that’s passed during runtime.
And finally, we modify the routes to accomodate the new URL style as shown below.
GET /hello/:name controllers.Application.sayHello(name)
Pretty cool, isn’t? Running http://localhost:9000/hello/Sam will give you the output as shown in figure 9.0.
Figure 9.0. RESTful style
Play vs. Node.JS
In the beginning, when I was working with Play framework, only one point kept crossing my mind. Oh, this looks a lot similar to Node.JS with Express. And boy, I was right. There is lot of debate going on between the two. And there’s a popular slideshare presentation comparing the two, by Yevgenly Brikman of LinkedIn. The presentation compares Play and Node.JS in detail, which I feel is a good source of information when you are architecting an application. You can view the presentation at http://www.slideshare.net/brikis98/nodejs-vs-play-framework?qid=d6c0b0da-bd29-4be4-93e2-ae0dadaea769&v=default&b=&from_search=1.