sbt 项目继承并扩展了 Maven 的默认项目布局, 加入了 Scala 代码的支持, 所以目录如 Shell 命令 mkdir -p src/{main,test}/{java,scala,resources} 生成的目录结构, 即

.
└── src
    ├── main
    │   ├── java
    │   ├── resources
    │   └── scala
    └── test
        ├── java
        ├── resources
        └── scala

这个目录目录虽然很清晰, 但把 Java 和 Scala 代码拆在两处没多大必要, 其次是层次多了点. 因使用 Play Framework 时日有点久了, 比较习惯于 Play 2 改造后的项目布局. 我们启动到 Play 2 的 activator(其实就是加入了定制的 sbt) 控制台, 用命令看它的目录布局 Read More

此次研究的目的原本是要使得 Play Framwork 2 中单元测试能够并发执行, 包括 JUnit 和 Spec 的测试用例, Play 2 的 activator 就是一个 sbt 的包装. 开发中发现我们 Play 2 中的单元测试是按序执行的, 实际上 sbt 下测试用例默认是并发执行的. 之所以 Play 2 的单元测试是按序的, 是因为 activator 设置了把 sbt 的两个属性 fork in Test := true 和 parallelExecution in Test := false, 见 PlaySettings.scala, 它们默认分别为 false 和 true. 这使得默认设置下 Play 2 中的所有测试无法并发执行.

sbt 默认的 fork 是 false, Play 2 改为 true 之后便可以使用 javaOptions in Test := "-Dkey1=value1" (注: 如果 fork 为 false 的话, javaOptions 将无效.) 往单元测试中参数了, 这也是为什么在 Play 2 的单元测试中无法获得启动 sbt 时(像 sbt -Dkey1=value) 的参数, 不同一个 JVM 啊.

那是不把 Play 2 的 fork in Test 和 parallelExecution in Test 分别改回成 false 和 true 就可以让测试用例并发执行了呢? 答案是 Yes. 但我们得相信 Play 2 把它们预设为 true 和 false 是有它的用意的, 比如集成测试的每个用例都会开启本地的 3333 端口, 如果让两个集成测试同时执行将会造成端口冲突. 细致说来, Play 2 其实是懒政, 只管一刀切而让所有测试按序执行而影响了效率, 如能利用好 sbt 的测试分组机制是可以达到测试的并发执行的.

这里引出 sbt 执行测试的几个机制:

1) sbt 总是对测试进行分组, 默认时所有的测试都包含在 <default> 组中, 可用 show testGrouping 查看, 如
Read More

我们用 Playframework 2 时，当 routes 中太多的路由配置时，我们可能会考虑把它们归类分布到多个文件中去。比如按 API 或用途分，有些是 RESTful API，有些是 Web 页面的，对于这种情景，我们可以由以下几个文件来组织：

1. routes 文件，这个仍然是充当入口

这里穿插着来解释下，-> 是固定写法，表示要去别外寻找了，紧接着的 /, /api, 和 /web 是分类路由的上下文了，例如，访问 api.routes 中定义的 /customers 的完整 API 路径就是 /test/customers。最后一部分是全类名，并非指别的路由文件的名称，像文件 general.routes 编译后会生成 general 包下生成  Routes.scala 文件，即类为 general.Routes. Read More

在上一篇 Play2 自定义模板类型 (Java&Scala)，是基于 Play2.2 怎么自定义 Json 模板类型，分别用 Java 和 Scala 实现。从 Play2.3 开始，模板明确了是用 Twirl，所以构建文件上的配置略有不同，并且模板编译出的源文件位置也不一样，Play2.2 前生成的模板源文件在 target/scala-2.10/src_managed/main/views 目录，现在是生成在 target/twirl/main/views 目录。

在 Play2.3 中仍然是默认只支持 html, txt, xml, js 四种类型的模板，见 SbtTwirl。我们这里还是以增加 Json 模板支持为例，且只介绍用 Java 的方式。因为 Play2 尽管可以用 Java 来编写应用，但实现部份基本是 Scala，所以如果用 Scala 来进行扩展相对来说来比用 Java 简单些。

Play2.3 官方的自定义模板的文档 Adding support for a custom format to the template engine 有些出入，似乎还未来得急更新，以实操为证。

还是从构建文件开始 Read More

Play2 默认支持的模板类型是 html, txt, xml 和 js，不在这些支持之列的模板文件即使放到 app/views 目录中，也不会被编译的。如果要支持自定义的模板类型就要些定制了，这比 Play1 复杂些。模板的定制包括在 Build.scala 或 build.sbt 中加上 templatesTypes 配置，并需创建 BufferedContent 和 Format 实现类。下面以增加 json 模板类型为例，兼顾 Scala 和 Java 的实现类，是基于 Play2.2 的，在 Play2.3 中又略有不同。

官方有相关的文档，参考：Custom formats on Scala, Custom formats on Java 和 模板定义参考.

在较新一些的 2.2 的 PlaySettings 中，可以看到


弄清了上面的原理后，开始我们的步骤

第一步：修改项目构建文件

在构建文件 build.sbt 或 Build.scala 中增加下面的内容作为项目的 setting Read More

伴随着 Play1, 我们原来使用的 JSON 库是 Gson. 回忆下 Gson 是怎么自定义序列化对象的 JSON 格式，大概是这样子的

GsonBuilder()..registerTypeHierarchyAdapter(Cat.class, new Cat());

然后 Cat 需要实现 JsonSerializer 的 serialize() 方法。

来到了 Play2 中，JSON 库变成了 Jackson，那么 Jackson 该如何为对象自定义 JSON 格式呢？

例如，默认时 Jackson 对 Map 类型输出的是一个 JSON 对象

Map("key1"->"value1", "key2"->"value2")     转换成 JSON 是 {"key1":"value1", "key2":"value2"}

当为适应某些客户端，对于 LinkedHashMap 类型，我们想要输出的是一个有序的 JSON 数组： [{"key1":"value1"},{"key2":"value2"}]

我们就应该自定义某些 Map 的序列化格式，实现方法有两种，addSerializer 和 @JsonSerialize，不管哪种方式都需事先具体化 JsonSerializer 类，并实现它的 serialize 抽象方法

所以我先来实现一个能序列化 Map 的 JsonArrayMapSerializer 类 Read More

用过 PlayFramework 的都知道默认的路由器文件是 conf/routes，Play2 可以定义自己的 routes 文件。在默认的 application.conf 中有这么一段注释

# Router
# ~~~~~
# Define the Router object to use for this application.
# This router will be looked up first when the application is starting up,
# so make sure this is the entry point.
# Furthermore, it's assumed your route file is named properly.
# So for an application router like `conf/my.application.Router`,
# you may need to define a router file `my.application.routes`.
# Default to Routes in the root package (and `conf/routes`)
# application.router=my.application.Routes

也就是通过 application.router 可以定义自己的 routes 文件。上面的解释很容易把人搞混，问题在于何处是文件路径，何处是类路径，至少写着的 'conf/my.applicaton.Router 就是在混淆视听。对于上面的解释要明白下面几点 Read More

用过 PlayFramework 的同学们应该都知道，Action 方法间的调用是进行的  302 重定向操作。

简单例子说明一下，当基于下面的 r1, r2 路由配置时，如果 Application.f1() 方法中调用了 f2() 方法，实际运作是 f1() 在调用 f2() 时，会先反向出 f2() 方法对应的路由  GET /r2，然后向 /r2 发出的一个 302 跳转.

上面也算是绕个弯形成了对 f2() 方法的调用，这也是非常合理，在 Action 中很容易理解的。

GET /r1 Application.f1
GET /r2 Application.f2
GET /r3 Application.f3

为什么说会反向出 f2() 方法对应的路由，可以反证一下。

例如说在 f1() 中调用了一个 public static void f4() 方法，但是 f4() 并未出现在 routes 配置中，也就是 f4() 没有对应的路由配置，我们将会看到这样一个异常 Read More

最早是用 HTML 来自定义标签，现在觉得 HTML 写有关逻辑的代码就有点不伦不类了，HTML 里着重是显示代码。前有一篇  PlayFramework 1 模板应用 -- Java 对象扩展 学习了对 Java 对象扩展的方式，如果不是基于已有对象类型进行方法扩展来进行调用，就可以自定义 FastTags 的方式。

Java 对象扩展的使用是 ${obj.abc()}, FastTags 标签是 #{abc}...${/abc}。

FastTags 标签类继承自 play.templates.FastTags，标签对应方法的原型是

public static void _tagName(Map<?, ?> args, Closure body, PrintWriter out, ExecutableTemplate template, int fromLine)

这些都是得益约定优于配置，下面来几个例子，分别说明默认参数，命名参数，及多参数，标签体的处理。 Read More