Unmi 注: 当你采用 TDD 进行开发过一段时间后，很快你就会对 TDD 产生依恋了。没直正去实践过 TDD，对于测试先行的提法只会觉得是一种理想状态。其实不然，从此开发模式变成 测试->实现->重构，同时也指导你的设计，基础架构并不需要那么稳定，它总在应需而变。所以 TDD 让你不该总在项目中后期抱怨架构设计不好之类的事，因为主动权一直在你。废话一堆后就是：测试真的很重要，尽快进入角色吧。
测试你的应用程序
测试源代码文件必须放置在你的应用的 test 目录下. 你可以在 Play 控制台下用 test 和 test-only 任务来运行它们.
使用 specs2
测试一个 Play 2 应用默认的方式是采用 specs2.
单元规格须继承自 org.specs2.mutable.Specification 特质并应用 should/in 的格式: 阅读全文 >>
Unmi 注: 有了前面对 Play 2.0 的 Json 支持的了解。见：1. Play 2.0 中文资料 - Play JSON 库，2. Play 2.0 中文资料 - 处理和响应 JSON 请求， 3. Play 2.0 中文资料 - Play JSON 库使用泛型。现在来看 Play 2.0 对 XML 的支持就更简单了，原因是 Scala 使用 Json 还需依赖于第三方的库 Jackson，而 Scala 对 XML 的支持直接利益于它的内建语法。如在 Scala 控制台下：
上面演示了 Scala XML 遍历 XML，访问属性，文本节点。方法和遍历 JSON 类似，也有 \ 和 \\ 方法。例如 user\"@name" 访问 name 属性。
而且有了 Scala 这样的内建语法，想要实现 toXML, fromXML 方法也很简单。
处理 XML 请求
XML 请求是指请求体为一个有效的 XML 数据的 HTTP 请求. 必须用 Content-Type 头指定 MIME 类型为 text/xml. 阅读全文 >>
概述
当使用基于 JSON 库的 typeclass(Unmi: typeclass 还没摸准翻译成什么词较合适，此前译作 类型类，觉得有点不妥，所以暂时保留原样) 时，可能会把泛型支持包含进这些 typeclass 中来. 针对基于终端控制查询参数，使用基本的结构作为查询结果的 REST API 来说可能是一个很好的应用方式.
Scala 对泛型的支持
给定如下基本的结构作为搜索结果:
|
1 2 3 4 5 6 |
case class SearchResults[T]( elements: List[T], page: Int, pageSize: Int, total :Int ) |
Unmi 注: 上面 case class 涉及到了 Scala 的样本类的特性，Scala 会给这个类自动添加一些句法：1）添加与类名一致的工厂方法，2）参数列表中的所有参数前隐式获得了 val 前缀，即会由相应的的实例变量保持状态，3）自动添加了 toString, hashCode, 和 equals 方法。 阅读全文 >>
处理 JSON 请求
JSON 请求是一个以有效的 JSON 数据作为请求体的 HTTP 请求. 它必须指定 Content-Type 头为 text/json 或是 application/json 作为 mime 类型.
默认的， Action 使用 any content 作为 Body 解析器, 这让你接收 Body 并解析为 JSON (实际为 JsValue):
|
1 2 3 4 5 6 7 8 9 10 11 |
def sayHello = Action { request => request.body.asJson.map { json => (json \ "name").asOpt[String].map { name => Ok("Hello " + name) }.getOrElse { BadRequest("Missing parameter [name]") } }.getOrElse { BadRequest("Expecting Json data") } } |
更好的(也是更简单的)办法是指定你自己的 BodyParser 用以告诉 Play 把类容 Body 直接解析为 JSON: 阅读全文 >>
概述
推荐的处理 JSON 的方式是使用 Play 基于 JSON 库的类型类, 位置在 play.api.libs.json.
这个库是构建于 Jerkson, 之上的，它又是基于 Java 的超快的 JSON 库 Jackson 的 Scala 封闭。
Unmi 注：在 Play 1.x 所用的 JSON 库是 Gson，而 Play 2.0 后更换成了 Jackson。还得 Play 2.0 是基于 SBT 构建的，所以 Play 2.0 的所有的 jar 都是在 $PLAY_HOME/repository/local 目录中。
这样做的好处是无论是 Java 还是 Scala 的 Play 应用依赖了相同的底层库 (Jackson), 同时 Scala 用户可以享受到 Play’s JSON 所带来的额外的类型安全性.
play.api.libs.json 包含有七种 JSON 数据类型:
JsObjectJsNullJsUndefinedJsBooleanJsNumberJsArrayJsString上面的类型都继承自通用的 JSON 值类型, JsValue. 阅读全文 >>
模板, 实际作为简单函数存在的, 它可以任何你希望的方式被组合应用. 下面是一些通用场景的使用案例.
布局
我们来声明一个 views/main.scala.html 模板来用作主布局模板:
|
1 2 3 4 5 6 7 8 9 10 |
@(title: String)(content: Html) <!DOCTYPE html> <html> <head> <title>@title</title> </head> <body> <section class="content">@content</section> </body> </html> |
正如你所看到的, 这个模板有两个参数: 一个标题和一个 HTML 内容块. 现在我们可在另一个模板 views/Application/index.scala.html 中用它: 阅读全文 >>
Unmi 注：因为是 Web 框架，所以展示层必不可少，也就是接下来两章，我们进入到 Play2.0 中的模板引擎的世界，不同与Play 1.x 让你眼花缭乱的 ${}, #{}, @{}, @@{}, &{}, %{}% 和 {} 如此众多的标签样式，而在 Play 2.0 中只有一个魔幻的 @ 符号。这就叫化繁为简，Play 1.x 的模板是基于 Groovy 的，而 Play 2.0 是基于 Scala 的，它在效率上也改善不少。
基于 Scala 的类型安全的模板引擎
Play 2.0 带来了崭新而真正强大的基于 Scala 的模板引擎. 这一新引擎的设计灵感来自于 ASP.NET 的 Razor. 具体表现在:
本章介绍几种定义通用 Action 功能的方法.
基本的 Action 组合
我们首先从一个简单的日志装饰器(logging decorator) 开始: 我们想要记录下当前 Action 每次被调用的日志.
我们不直接就定义自己的 Action, 而是首先提供一个用于创建标准 Action 的帮助方法:
|
1 2 3 4 5 6 |
def LoggingAction(f: Request[AnyContent] => Result): Action[AnyContent] = { Action { request => Logger.info("Calling action") f(request) } } |
接着你可以这么来使用: 阅读全文 >>
什么是 Body 解析器?
HTTP PUT 或 POST 请求含有一个请求体(Body). 请求体可以使用任何格式, 只要在请求头中指定相应的 Content-Type 即可. 在 Play 中, 一个 Body 解析器 转换请求体为对应的 Scala 值.
然而，HTTP 请求体可能非常的大，这时候 Body 解析器 不可能在解析之前光等着把数据全部加载到内存. BodyParser[A] 是个基本的 Iteratee[Array[Byte],A], 这就是说它一块一块的接收数据 (只要 Web 浏览器在上传数据) 并计算出类型为 A 的值作为结果.
让我们考虑一下几个例子.
Iteratee[Array[Byte],String]).java.io.File 引用作为结果 (Iteratee[Array[Byte],File]).Iteratee[Array[Byte],S3ObjectId]). 阅读全文 >>会话和 Flash 域在 Play 中有何不同
如果你不得不要跨多个 HTTP 请求来保存数据, 你可以存在会话或是 Flash 域中. 存储在会话中的数据在整个会话期间可用, 而存储在 Flash 域中数据只对下一次请求有效.
理解到会话和 Flash 数据不是由服务器来存储，而是以 Cookie 机制添加到每一次后续的 HTTP 请求是很重要的. 这也就意味着数据的大小是很受限的 (不到 4 KB) ，而且你只能存储字符串.
当然了, Cookie 值是由密钥签名了的，这使得客户端不存修改 Cookie 数据(或者说这样做会让它失效).
Play 会话不能当成缓存来用. 假如你需要缓存与某一会话相关的数据, 你可以使用 Play 内置的缓存机制并存储一个唯一的 ID 在用户会话中与之关联.
会话没有技术上的超时控制. 它在用户关闭 Web 浏览器后就会过期. 如果你的应用需要一种功能性的超时控制, 那就在用户会话中存储一个时间戳，并在应用需要的时候用它 (例如: 最大的会话持续时间, 最大的非活动时间, 等等.).
读取会话值
你可以从 HTTP 请求中获取传入的会话: 阅读全文 >>