Category: PlayFramework

自定义 Spring Web Controller 方法的参数

2022-07-07 | 阅读(323)

在 Spring Web Controller 方法中的参数可用 org.springframework.web.bind.annotation 下的各种注解来说明参数值从哪儿获得，比如我们熟知的 @PathVariable, @RequestParam, @RequestHeader, @RequestBody, 还有较少使用的 @ReqeustAttribute, @SessionAttribute, @RequestPart, @MatrixVariable, @ModelAttribute, @AuthenticationPrincipal, @CurrentSecurityContext 等。其实在它们背后工作的是相应的 HandlerMethodArgumentResolver 的子孙们，当然还有 HttpMessageConverter 的各个实现类还默默的对输入数据进入类型转换。

为进一步深入了解 Spring Web 如何获得用户输入，我们先尝试一下不常用的注解，然后实现一个自己的注解参数 @ProductId, 它来从 queryString 或 requestHeader 中获得 productId。写作本文的起因是在上一篇 理解 Spring Boot Security + JWT Token 的简单应用 里, JwtTokenFilter 住 SecurityContextFilter 放一个 Authentication 实例, 在 Controller 方法中便能用 @AuthenticationPrincipal 自动注入 authentication.getPrincipal() 的值。 阅读全文 >>

建立 Play 2 框架一样的目录布局

2016-04-15 | 阅读(421)

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) 控制台, 用命令看它的目录布局 阅读全文 >>

sbt 中单元测试并发执行

2016-04-13 | 阅读(1,138)

此次研究的目的原本是要使得 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 查看, 如

阅读全文 >>

拆分 Playframework 2 的 routes 为多个文件

2016-02-22 | 阅读(935)

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

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

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

Play2.3 自定义模板类型 -- Java 版

2014-09-07 | 阅读(1,001)

在上一篇 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 有些出入，似乎还未来得急更新，以实操为证。

还是从构建文件开始 阅读全文 >>

Play2 自定义模板类型 (Java&Scala)

2014-09-03 | 阅读(862)

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 阅读全文 >>

为 Jackson 自定义序列化对象的 JSON 格式

2014-06-12 | 阅读(4,816)

伴随着 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 类 阅读全文 >>

Play2 中使用自定义的路由器文件 routes

2014-05-08 | 阅读(1,113)

用过 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 就是在混淆视听。对于上面的解释要明白下面几点 阅读全文 >>

Play1 直接调用 Action 方法，不作 302 跳转

2014-05-02 | 阅读(984)

用过 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() 没有对应的路由配置，我们将会看到这样一个异常 阅读全文 >>

PlayFramework 1 自定义标签 -- FastTags

2014-04-14 | 阅读(1,282)

最早是用 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)

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