Review of new features in playframework v2

Good day to all. I would like to bring to your attention a brief description of the new features of Play 2. This article is about play2 scala.

To begin, tell you a little about yourself and play. From 2008 to 2010, I worked on the play development team, then we worked hard on the playm community (versions 1.0 and 1.1). I replaced the team with this comment, but I often see my former colleagues and continue to use play in most projects. The play itself came from a single proprietary project that we implemented for one of the largest French banks. In general, if anyone is interested, I can write about the history of play in a separate article.

The role of scala and java

If earlier scala support in play was implemented in a special module, then since version 2, scala is a full member of the framework on a par with java. To be precise, we can say that many play 2 bricks are made on scala and can be used in java.

Project building system

Previously, play had its own project building system implemented in the form of scripts / classes in python, bash, batch. Later, there were people who at the end defiled my favorite framework and screwed it with a maven (maven) in the form of a separate module. Now the whole project building system is built on sbt + play sbt plugin (well, a little bash, where batch is without).
')

Play console

In the new version of play got this console. Now you have the opportunity to compile, test, run your project (etc.) directly from the console. In general, the play console is just an add-on to the sbt console.

Controllers and actions

Now in play all your actions (actions) should return a special type - result (result). In the scala part there is a special helper - action for this:

def index = Action {
Ok ( "Hello world!" )
}

This is a simple example of using action. Believe me, you have the ability to perform much more complex manipulations.

Routing (routes)

The second version did not avoid changes and the mechanism of rutting. Now you obviously need to specify your http parameters for each action in the routes file.

GET / controllers. Application . index
POST /: id controllers. Application . new1 ( id: int )

If you design a root card before creating actions and controllers, you may encounter compilation errors, since you specified nonexistent actions. In this case, you can use the predefined action - TODO which returns 503 in case of a call.

object Application extends Controller {
def index = TODO
def new1 ( id: Long ) = TODO
}

View

As you can see in play 2, a new kind of script engine based on scala and similar to ASP.NET Razor was implemented. The engine is very powerful and at the same time easy to learn.

Model

In play 2, you can use jdbc or Anorm or something else as a model , for example ScalaQuery or if you try jpa, which I wouldn’t recommend. If you're interested, then I could put in a separate article an introduction to Anorm.

Akka integration

You do not recognize the asynchronous part in play 2, it has been redone using Akka 2.0. You can configure your actor system directly in the configuration file, or if you don’t like the built-in actor system, you can use any other system.

akka default -dispatcher. core -pool-size-max = 64
akka debug . receive = on

You still have the opportunity to run tasks asynchronously, only now this is not done by means of annotations but a little differently, so to speak, more and more in the spirit of dsl.

Akka. system . scheduler . schedule ( 0 seconds, 30 minutes, testMe, “me” )

Asynchronous HTTP

Since the entire internal architecture of play is built on netty, thanks to this we have access to such great features as WebSocket or asynchronous use of the HTTP protocol. Sometimes you need to perform some kind of resource-intensive operation in one of your controllers, it is for such situations that async HTTP comes in handy for you. All you need to do in this case is to change the result type in your action from SimpleResult to AsyncResult .

def index = Action {
val promise = Akka. future { computation ( ) }
Async {
promise. map ( result = > Ok ( "Got result:" + result ) )
}
}

Work with json

Also in the play 2 were added homegrown API to work with json, in my opinion not the most convenient. Reading json still did not go far (in simple cases), but converting from objects to json, in my opinion, is very lame.

Reading:

( ( Json parse string ) "node1" "node2" ) . asOpt [ String ]

Build:

Json toJson Seq ( toJson ( 1 ) , toJson ( "Bob" ) , toJson ( 3 ) , toJson ( 4 ) )

Although you always have the opportunity to use external libraries as in earlier versions of play.

Global object

The global object acts as a bootstrap class for your application. It can wedge in such events of your application as onStart , onStop , onError , onActionNotFound , and so on. This is a kind of replacement for @OnApplicationStart and from async jobs play 1. *. Here is an example of using such an object:

object Global extends GlobalSettings {

override def onStart ( app: Application ) {
Logger info ( "Application has started" )
}

override def onStop ( app: Application ) {
Logger info ( "Application shutdown ..." )
}
}

Tests

Here I will only say about the part of scala. Finally, it became possible to use a third-party library for testing, namely specs2 with mockito support. In addition, testing remains as convenient as before.

Conclusion

This article is only a superficial overview of the capabilities of the play 2 framework. If you are interested, then I can bring to your attention more detailed reviews on such topics as:

• Anorm and other light orm in play2
• MVC play2 in detail
• Play2 in production
• Etc

Thanks for attention.