play framework2.5.

play framework2 的学习笔记

https://github.com/playframework/playframework

https://github.com/playframework/playframework.com

1.语言部分
1.1.文档中说每个视图视图就是函数，个人以为，从声明的方式来看视图更像是类，因为其中可以定义重用的方法，也能插入别的视图。从调用的方式来看的确很像函数。

2.play特性
2.1.使用SBT编译系统
以前开发bs程序都是由javac给你把java文件编译成classes文件，现在不同了，必须由SBT系统来编译/发布和运行才行，eclipse之类的IDE环境只是个带语法检查功能的写字板而已。

2.2.性能
play framework 2服务器是基于高性能的apache mina开发的，因此性能不俗（支持集群），据官网说自己的性能很好，比其他任何服务器都快，我没有做过这方面测试，所以不好评价。

2.3.第三方jar包
必须放在工程目录\lib目录里，否则无法编译，注意，加入新jar包后要重新在控制台执行

eclipsify with-source=true

否则eclipse不会自动加包，当然了你也可以不用指令手工设置。

2.4.ehcache缓存
play 2自带ehcache，无需编写ehcache.xml（play2已经包含了ehcache.xml）,直接就能用。

2.5.模块和插件
到目前为止，我还没有办法找出来模块和插件的区别在哪里，给我的感觉两者是一回事。
play2提供了很多插件，在https://github.com/playframework/Play20/wiki/Modules可以下载

2.6.约定优于配置
这是ROR的特点之一，也是优点，在play2中Global.java类就是这个特性的体现，Global.java是继承自GlobalSettings的类，用于实现一些全局的功能，比如类似Listener和Filter的功能之类。Global.java必须是这个名字而且必须放在app目录下，否则是不起作用的。类似的东西还有好多，如果有文档还好点，没有文档只能自己在play framework2源码里找了。

2.7.导出成war包
play2默认是无法到处成war包的，好在有一个叫play2-war-plugin的插件可以帮我们打包成war包，这个插件在 https://github.com/dlecan/play2-war-plugin 可以下载，毕竟Play是另起炉灶，和J2ee标准差别比较大，所以这个插件是有不少局限的，比如必须发布为ROOT.war，还有对servlet版本有要求等等。

2.8.升级play工程
升级了play版本后（只是2.x版本之间的升级，1.x到2.x升级并不适用），工程中执行play会出现提示信息

Update the Play sbt-plugin version to 2.0.3 (usually in project/plugins.sbt)

你需要

a.修改project/plugins.sbt，把其中的版本号改成最新的版本号
b.执行update命令
c.重新执行eclipse with-source=true

3.表现层部分
3.1.视图是需要编译的
视图是需要编译的，和java文件一样，也是由SBT来编译，然后通过控制器来调用和渲染。和JSP有点像。

3.2.视图的使用需要注意
刚刚接触scala template，在使用视图的语法困惑了一阵子

@main(title="home"){
<h1>hello world</h1>
}

明明main.scala.html里面定义了@title和@content两个参数，怎么这里只使用了一个？而且@content参数是如何传入的？
后来琢磨了一下，总算是弄清楚了，视图的参数传递很灵活，可以和python一样用指定名字传参数title="hme"，也可以按照参数顺序来传递，其实上面的代码参数传递应该是这样的

@main(title="home")(content="<h1>hello world</h1>")

下面的几种写法都是正确的

@main(content="<h1>hello world</h1>")(title="home")
@main{home}{<h1>hello world</h1>}

甚至可以写成

@p1={home}
@p2={<h1>hello world</h1>}
@main(title=p1)(body=p2)

3.3.控制器中调用视图的方法
例如视图的名字叫做demo1.scal.html，其中有一个name参数
那么在Controller中，直接用views.html.demo1.render("jim")来打开views/demo1.scala.html视图并渲染，其中的参数和视图中声明的一致。
如果在开发工具中使用自动完成功能找不到这个demo1或者提示的参数是错误的，那就可以说明视图未编译，需要在工程目录中先执行compile命令编译，然后再刷新工程就ok了。
3.4.scala视图的困扰
视图不像文档描述的那么简单，但也不是非常难。
困难的原因：
* Scala语法实在太灵活，也太晦涩，基本上你以前掌握的编程技能和语法在Scala里很多都是没用的，最起码我是从头认认真真的学了Scala的，学完仍是云里雾里的一知半解。
* 目前仍然没有一款和JSP/HTML编辑器那样的出色的，带语法检查，自动完成，语法着色的Scala视图编辑器，尤其是缺少和主流开发环境集成的编辑器插件。这就意味着你只有在运行时才能知道刚才弄的视图语法是否有错。
* 没法用网页设计工具来直接设计视图，你只能先设计，再改成视图，如果需要进一步修改外观，就只能把应用运行起来在线预览和借助firebug之类的调试工具了。（估计这会让美工和前端工程师手足无措的）。

几个好消息：
* 对于开发Scala视图来说，只要你弄清楚最简单的scala语法和流程控制命令就够用了，太高级的功能根本用不着。
* play服务器具备刷新即可显示变化的特点，所以改变了代码后直接刷新浏览器，然后看浏览器上的错误信息来修正代码是唯一的除错手段（不能不说，play给出的错误提示不但完整而且清晰准确）。这就比开发j2ee程序时药省去了不少时间。
* Scala同时支持指令方编程和函数式编程，指令式就是说的java那样的编程方式，个人认为这种编程风格更容易上手，也符合从java转过来的开发人员的编程习惯。

3.5.Scala视图里的泛型表示
在Scala视图里用[]表示泛型，所以List[String]就相当与java里的List

3.6.play里对XML的处理
play使用的是w3c的DOM解析器，而不是我熟悉的dom4j，不过play自带一个XPath库 play.libs.XPath，倒是也不难
多个节点：List<Node> list = XPath.selectNodes("//name", doc);
单一节点：XPath.selectText("//name", doc);
也挺简单的。

3.7.Scala视图里对XML的处理
视图里也可以直接处理XML，根本不用拼字符串，很方便。

3.8.自带缓存功能
用法特简单
缓存数据：

Cache.set("name", "jim");
String name = Cache.get("name");
Cache.remove("name");

缓存http响应：

@Cached("homepage")
public static Result index(){
  return ok("hello world");
}

缓存视图

@cache.Cace.getOrElse("cache-content", 3600){

i'm cached for an hour

} 3.9.LESS Less是一种动态样式表语言，扩展名是less，里面可以用变量，继承，运算等编程语言中常见的内容编译生成css。play framework2支持less作为样式表 3.9.1.几个要点

a.less必须放在app/assets/stylesheets目录下 b.编译后的样式表会输出到target/scala-x.x.x/resource_managed/main/public/stylesheets目录下，如果你的less文件是demo1.less，那么会生成demo1.css和demo1.min.css。 c.执行play compile不会编译less，只有运行时才会编译（至少play 2.0.2是这样的） d.在*.scala.html中像正常那么引入css就可以了，而不用管css有没有生成 个人感觉less对于需要大量编写css的开发者比较好使，但对于奉行拿来主义的开发者来说，除了能检查css是否有错和生成的css体积较小外，没什么特别的优点。

3.10.twitterbootstrap twitterbootstrap是twitter团队写的一套css框架包，基本上你想做网页外观样式，他们都提供了，你只要设置一下class就可以了，很省事，但是twitterbootstrap并不适合中国国情，因为国内仍然有着大量的ie6用户，twitterbootstrap对ie系列支持的比较糟糕，个人认为，在现阶段最好不要用twitterbootstrap，可以考虑别的一些框架，比如jquery ui，blueprint，960 grid system，yui css framework之类，这些框架对ie支持的不错。 3.11.图片的引用 在css中往往会引用一些图片，比如设置个背景图什么的，像这种情况一定要用相对路径，例如路径如下

public/ public/stylesheets/main.css public/javascripts public/images

图片统一放到images目录下，css中声明如下

 background: url('../images/back_enabled.png')

这样就可以正常访问了。

3.12.样式表/图片/js提供缓存处理
play的服务器是采用Apache Mina网络框架开发的，提供了很多友好的功能，比如自带缓存功能，自动重新载入class。
不过，play服务器是否能用于生产环境还有待进一步观察。

3.13.实现Servlet里Filter的功能
有两种方法

方法1：继承GlobalSettings类，重写onRequest()方法，return super.onRequest(request, actionMethod)即可执行原方法，否则就不执行。
方法2：使用@With也可以实现Filter的功能

3.14.实现Servlet里Listener的功能
继承GlobalSettings类，实现onStart()方法和onStop()方法

4.持久层部分
4.1.Play里的持久层
目前Play提供可用的持久层有三个
第一个是早期提供的Anorm，提供简单的SQL数据访问功能，这个框架功能类似spring的jdbctemplate。
第二个是从Play2.0开始提供的ORM框架EBean，用法和JPA差不多。
第三个是JPA。
说实话，个人认为，持久层框架的选择依据应该是选你最熟悉和最了解的，别追求什么高科技。而且play并没有限制你必须用什么持久框架。
比如我对mybatis情有独钟，个人感觉mybatis做sql优化非常容易，这对于复杂的查询来说特别重要。只是mybatis和play2集成的文章挺少的，我做了一个demo，请参看我的另一篇文章play2+guice+mybatis+ehcache+mmysql范例(java版)j2ee

5.测试
5.1.单元测试很方便
只要把基于junit的单元测试类都放到test目录下，在控制台运行play test就能自动执行所有测试了，很方便。
play2甚至已经集成了HttpMock功能，用法很简单

public class FakeAppTests {
    @Test
    public void t1(){
       running(fakeApplication(), new Runnable() {
            public void run() {
                Result result = callAction(controllers.routes.ref.Application.index());
                Assert.assertEquals(OK, status(result));
                System.out.println(Helpers.contentAsString(result));
            }
         });
    }

play2的单元测试功能简直太棒了，对于测试驱动开发非常有帮助。
6.常见问题
6.1.偶尔出现的无法编译问题解决办法（代码没错误）
偶尔会发生代码无法编译的情况，尤其是在你执行了clean命令之后，出现这个问题后，一般可以先把project/scala-2.9.1/src_managed加入源码路径一般就可以了。也不总是灵验的，总之我遇到这问题后就是在加路径，重启eclipse，clean，compile这几个动作之间来回折腾，往往折腾几次后，恼人的编译失败问题就搞定了。

6.2.play的资料太少了
只有一份官方出的手册比较有针对性，但这文档写的太笼统了，只能凑合看，play 1.x的书倒是有几本，但和Play2区别还是挺大的，刚刚入门最好别看play1.x的书，否则会给领沟里去。

6.3.play的开发模式和流程
对于用惯了j2ee开发环境的人来说，刚刚上手play2的开发还是挺不适应的，因为play2的开发全靠着play控制台，而对ide要求不好，甚至你用记事本就可以做play开发。
而且调试比较费劲，必须开启调试模式，然后在eclipse远程调试attach9999端口才能调试，而且eclipse控制台里还不显示日志信息，总之就是一个不习惯。其实这是因为play更多的依重单元测试来完成开发工作的，一般的play开发流程是这样的
开发流程主要分三大块

一.编写单元测试->修改routes文件->修改Controller->编写*.scala.html 到了这里，其实程序都还没有运行过一次，代码里面也是有很多错误，eclipse红色的错误一大片，视图模板也没法预览，显示成什么样子都不知道。
二.开始运行单元测试，调试业务功能，调试视图输出，不断的迭代修改，直到测试通过为止。
三.然后再正式运行服务，在浏览器里查看页面显示格式，修改*.scala.html页面模板，修改显示直到符合要求。基本上就是这么个流程，和以前在tomcat下开发是有很大不同的，如果不按照测试驱动的开发思路做play项目的话，只能起到事倍功半的效果。

这样做的最终结果是你得到了一大堆的单元测试程序，这些单元测试程序对于保证你项目的稳定性和强壮性有者至关重要的价值，尤其是大项目重构时，其价值尤其重要。

总结
play 2功能还是很强悍的，非常适合快速开发B/S应用，而且内置了常用的框架和组件，上手挺快，比J2EE简单多了。