Modüller ve Pluginler

Books

Previously, results could be either plain or async, chunked or simple. Having to deal with all these different types made action composition and filters hard to implement, since often there was functionality that needed to be applied to all types of results, but code had to implemented to recursively unwrap asynchronous results and to apply the same logic to chunked and simple results.

It also created an artificial distinction between asynchronous and synchronous actions in Play, which caused confusion, leading people to think that Play could operate in a synchronous and asynchronous modes. In fact, Play is 100% asynchronous, the only thing that differentiates whether a result is returned asynchronously or not is whether other asynchronous actions, such as IO, need to be done during action processing.

So we’ve simplified the structure for results in Java and Scala. There is now only one result type, SimpleResult. The Result superclass still works in many places but is deprecated.

In Java applications, this means actions can now just return Promise<SimpleResult> if they wish to do asynchronous processing during a request, while Scala applications can use the async action builder, like this:

How and when Play buffers results is now better expressed in the Scala API, SimpleResult has a new property called connection, which is of type HttpConnection.

If set to Close, the response will be closed once the body is sent, and no buffering will be attempted. If set to KeepAlive, Play will make a best effort attempt to keep the connection alive, in accordance to the HTTP spec, buffering the response if only no transfer encoding or content length is specified.

The resulting action builder can be used just like the built in Action object, with optional parser and request parameters, and async variants. The type of the request parameter passed to the action will be the type specified by the builder, in the above case, AuthenticatedRequest:

Execution contexts are now required when calling on methods of Iteratee, Enumeratee and Enumerator. Having execution contexts exposed for the Iteratee library provides finer-grained control over where execution occurs and can lead to performance improvements in some cases.

Execution contexts can be supplied implicitly which means that there is little impact on the code that uses Iteratees.

The playJavaSettings now declares all that is required for a Java project. Similarly playScalaSettings exists for Play Scala projects. Check out the sample projects for examples of this new build configuration. Note that the previous method of using build.scala along with play.Project is still supported.

For more information on what has changed for sbt 0.13 please refer to its release notes

The benefit in using the Native Packager is that many types of archive can now be supported in addition to regular zip files e.g. tar.gz, RPM, OS X disk images, Microsoft Installers (MSI) and more. In addition a Windows batch script is now provided for Play as well as a Unix one.