-Flyぁ梦- » Play http://blog.11034.org Sun, 22 Jun 2025 08:59:05 +0000 zh-CN hourly 1 https://wordpress.org/?v=4.2.38 Play框架中Action的参数绑定和验证 http://blog.11034.org/2012-05/param_binding_in_play_framework.html http://blog.11034.org/2012-05/param_binding_in_play_framework.html#comments Mon, 14 May 2012 16:28:31 +0000 http://blog.stariy.org/?p=1158 再来讲讲Play框架中Action的参数绑定，用过的都说好，哈哈。不仅可以将任意字符串值（比如用户名和密码）、日期值（生日）、整数值（第几页、年龄等）直接作为Action方法的参数放入其中自动绑定，还可以对继承自play.db.jpa.JAPBase的Model类进行直接的封装，这对一个具有很多变量的JavaBean来说实在是一件令人惊喜的事情，省略了太多太多重复又难看的代码有木有！

另外一个令人感觉兴奋的就是参数验证机制，再也不用自己针对Model的每一个属性值去写判断检验的代码，也不用像Struts那样要写复杂的xml文件去作验证，现在的框架十分流行Annotation，只要在Model类中给每个属性上一个类似@Required、@Email、@Phone、@MaxSize之类的注解，剩下的工作Play全部自动会完成了，你最后需要的只是给这个Model类传入Action方法时加一个@Valid注解或者在Action方法中调用validation.valid(obj)就OK了。

其实方法动态参数绑定这点在Spring MVC中也已经有了，但是一般只用来传入HttpServletRequest和HttpServletResponse。

当执行到play.mvc.ActionInvoker.invoke()时，在调用完resolve(request, response)后Play的路由工作已经完成，具体可参见Play框架的Router机制和jregex包一文。然后得到了需要调用的Action方法的Method类，在真正调用Action前，就需要执行完参数绑定的工作，如果参数带有@Valid或者@As注解，还要进行验证工作。代码继续执行：

	Play.pluginCollection.beforeActionInvocation(actionMethod);

这句话调用Play的插件机制，在调用Action方法前进行各种操作，算是一个Hook，这在Wordpress中非常常见。其中有一个插件play.data.validation.ValidationPlugin，它的工作在beforeActionInvocation(actionMethod)中会检查这个Action的所有参数是否带有任何注解，若有则在这里启动参数绑定和验证工作，若无则直接返回。

不管ValidationPlugin是否提前完成了工作，ActionInvoker.invoke()代码继续进行来到invokeControllerMethod(actionMethod)，然后在里面继续进行参数绑定和验证工作。

前面无论是ValidationPlugin还是后来调用的invokeControllerMethod(actionMethod)，真正进行参数绑定和验证工作的地方都在它们都会调用的

	ActionInvoker.getActionMethodArgs(Method method, Object o);

此函数先判断参数是否已经完成绑定工作（即之前是否已被ValidationPlugin调用过了），然后真正进入参数绑定和验证工作。

	Object[] rArgs = new Object[method.getParameterTypes().length];
	for (int i = 0; i < method.getParameterTypes().length; i++){
		Class type = method.getParameterTypes()[i];
		...
		rArgs[i] = Binder.bind(...);
	}

这个循环遍历Action Method中的每一个参数，然后通过play.data.binding.Binder类来执行具体的参数绑定工作。

	result = Play.pluginCollection.bind(parentParamNode, name, clazz, type, annotations);

首先这条语句再次遍历Play的插件集合来实现参数绑定，其中的play.db.jpa.JPAPlugin会跳出来完成参数是JPABase子类（一般为models包下的Model类）的参数绑定。这里会特判一下参数中是否带有id属性，若有则执行一条数据库查询获得此Model的这条数据的Object，若无则通过反射拿到无参构造重新new一个Object。然后就会调用play.db.jpa.GenericModel.edit()方法将参数绑定到这个Object中。在edit()方法中，通过反射获取JavaBean所有的Field（这边的Field若带有外键性质的注解，如@OneToOne，会触发递归绑定），绕了一圈最后调用Binder.internalBind()完成对每个Field的绑定。

如果参数不是JPABase的子类只是Java中的普通类，则直接调用Binder.internalBind()来搞定就好了。

	Binder.internalBind()

这个方法完成了对Java基本类型和一些常用的集合类、属性类的值绑定。

  1. 若Field是Enum或其子类，调用Binder.bindEnum()，由Enum.valueOf()实现
  2. 若Field是Map或其子类，调用Binder.bindMap()
  3. 若Field是Collection或其子类，调用Binder.bindCollection()
  4. 若Field是数组，调用Binder.bindArray()
  5. 都不是，则调用Binder.directBind()
  6. 在directBind中，会从Map<Class<?>, TypeBinder<?>> Binder.supportedTypes中寻找是否是Play指定的特殊的可以绑定的Java类，比如java.util下的Date、DateTime、Calendar或者java.io.File等，具体见Binder类的static初始化域
  7. 若也不是上面这些稍复杂的类型，那就是Java的基本类型了，按照String、Character、int或Integer、long或Long、double或Double、BigDecimal、boolean或Boolean这样的顺序依次解析和绑定
  8. 在internalBind中会catch住所有抛出的解析异常，从而调用Validation.addError()完成验证中添加错误信息的工作

这些类型的数据绑定中，若数据值为空，则相应地返回对应类型的默认值（0、0.0、false、new Object()等）。

至于参数验证，很简单地遍历每个Field根据其拥有的注解一个一个地去自动检查就好了，这没有难度，无论是@Valid注解还是手动调用validation.valid()方法都是差不多的。

的确还是很复杂，涉及到的代码也很多，所以当一个JavaBean的属性值不是太多时，还是建议一一获取属性值自己来组建Model类的方式比较好，一是效率更高，二是Html模板中也不用在input的name属性值中用model.field这种形式，感觉不是很好。

看看 Play , 框架 , 验证

看看 Java

  • 2016-09-09 -- 64位Linux下Java进程堆外内存迷之64M问题
  • 2016-08-18 -- 读java concurrency in practice
  • 2016-08-05 -- 线程清理
  • 2016-06-21 -- FutureTask简单分析和用法
  • 2016-06-21 -- Semaphore简单分析
    • ]]> http://blog.11034.org/2012-05/param_binding_in_play_framework.html/feed 3 Play框架的Router机制和jregex包 http://blog.11034.org/2012-05/router_in_play_framework.html http://blog.11034.org/2012-05/router_in_play_framework.html#comments Mon, 14 May 2012 16:23:37 +0000 http://blog.stariy.org/?p=1154 最近对Play框架兴趣甚浓，对其有兴趣的功能都想一探究竟，先研究了下它的Router机制。概要地说，主要使用routes文件和正则表达式来完成URL到函数的映射，不过这里正则表达式功能比较强可以解析出{id}这样的参数，因此Play使用了第三方jregex包而不是JDK的java.util.regex包来执行正则表达式的工作。

    Play的routes文件很清楚简单，每行一个Route，最重要的参数包含请求方式、请求URL和响应的函数，就像下面这一行：

    	GET	/customer/detail/{id}	CustomerController.detail

    Router机制机制具体包含解析和路由2个阶段。路由代码主要在play.mvc.Router和其静态内部类Route，解析Request代码主要在play.mvc.ActionInvoker中。

    1.route文件的解析和路由表的建立

    1. Play在启动初始化时，通过application.conf配置文件获取http.path参数，ctxPath = http.path;（这个就是相对路径啦）
    2. 调用Router.detectChanges(ctxPath);//若路由表没有建立或者routes文件被更新，解析文件
    3. 针对route文件的每一行（所以路由的顺序按照routes文件行的顺序为优先级），根据正则表达式获取method、path、action值，可能还有headers和params值
    4. 新建一条Route记录，并作一些解析计算（比如找出path中带有的参数信息）

    以上面提到那条示例的route为例，method = GET，path = /customer/detail/{id}，action = CustomerController.detail，在新建Route记录作解析计算时，会先将path利用正则表示式转化为/customer/detail/{<[^/]+>id}的形式，然后拿出所有的{id}形式的变量信息，再然后继续通过正则表达式再转化为

    	/customer/detail/({id}[^/]+)

    这样的形式，这也是path最后的pattern，用来去匹配请求的URL。这个形式的正则表达式，java.util.regex包无法解析，而jregex包是可以处理的，并且group的时候可以根据变量名来取变量值，很方便。

    2.URL的路由

    当一个Http请求过来，就遍历路由表，当一条Route记录可以匹配当前的path，就可以获得在routes文件中配置的action值，就比如上面的CustomerController.detail，并通过正则表达式获得路径中的参数（id=?）。然后解析action值得到Controller类名和Action方法名（action值若不以“controllers.”开头的话会被自动加上），通过Play框架中的ApplicationClassloader获取到Controller类的Class类，然后通过此Class类反射获取到具体Action的Method，将这些解析的结果都赋给play.mvc.Http的静态内部类Request中，URL路由就完成了。

    值得优化

    这样看来，其实这自定义URL的路由机制还是蛮简单的，如果去除了动态参数绑定、静态文件路由特判等一些特殊功能的话，那真的是很简单很容易实现了。而且感觉Play的路由代码还有很多可以值得优化：

    1. 不带动态参数的路由路径（就是纯字符串匹配）可以通过HashMap来匹配，而不用每条都去执行一遍正则表达式
    2. 每条路由对应的Controller类和调用的Action Method应该在路由表建立的时候就应该被解析完毕并存储在路由表中，而不是每一个http请求都重新解析一遍

    jregex包

    看Play源代码发现了这个包，官方网址：http://jregex.sourceforge.net/。网站上很好地比较了它与java.util.regex的优劣，用变量名去Group即网站上介绍的named groups，而且据它自己介绍性能比较高。觉得当一个应用大量用到正则表达式的话，jregex是比较推荐的。

    JRegex vs. java.util.regex

    • (+) JRegex is a Free Software
    • (+) JRegex is portable (runs under any version of java)
    • (+) JRegex supports more features (named groups, Perl5.6’s conditional statements and more)
    • (-) java.util.regex implements 2’d level of Unicode support (JRegex is level 1)
    • (-) JRegex is not a ‘standard’ library

    看看 Play , 框架 , 正则 , 路由

    看看 Java

    • 2016-09-09 -- 64位Linux下Java进程堆外内存迷之64M问题
    • 2016-08-18 -- 读java concurrency in practice
    • 2016-08-05 -- 线程清理
    • 2016-06-21 -- FutureTask简单分析和用法
    • 2016-06-21 -- Semaphore简单分析
      • ]]> http://blog.11034.org/2012-05/router_in_play_framework.html/feed 2 Java Play framework http://blog.11034.org/2012-05/java_play_framework.html http://blog.11034.org/2012-05/java_play_framework.html#comments Sun, 13 May 2012 05:19:29 +0000 http://blog.stariy.org/?p=1150 因本科几个老同学的邀请参与一个项目的开发，用到了这个全新的Java框架，“Play”。名字很有意思，接触的1.2.4版本而不是最近的2.o，上手很快，安装包里有自带的Sample程序。框架的易用程度大大超过了自己的预期，果然随着时代的发展Java框架越来越强大并且越来越人性化，最大程度地方便程序员开发应用。

      一直使用也看好Spring MVC，但是Spring的日益臃肿让这个框架的优势在不断流失。列举Play一些非常棒的地方，特别是较之Spring MVC的优势。

      • Play最大的一个特点就是开发期间每次修改Java代码无需重启Java Web服务器，瞬间感觉和写PHP程序一样方便！这个真的是太爽，之前写Java Web程序调试，每次关闭再重启Tomcat少说也得5秒钟吧。
      • 配置文件齐全，基本上帮你考虑到了所有可能要配置的内容（配置、持久、缓存、日志、国际化等）
      • URL route很清楚很简单，而且完全自定义URL Pattern（SpringMVC的Route还是不算太好，不能定义/model/action这样的url）
      • 一个Java类作为一个Controller可以每个方法都对应一个HTTP请求的方式，大量减少了类的数量
      • Controller的方法和Template文件对应很好，默认模式下自动对应，十分方便
      • 根据Action方法的参数类型和名称自动从提交参数中自动封装，包括对JavaBean的封装，对大量属性的表单特别有优势
      • 对传入参数的验证很容易而且基本不用再自己写代码，全部在Model类里用Annotation搞定
      • Action方法可方便返回Html、Text、Json、Xml等数据，各种方便的API
      • Model层真的简略到基本不用写任何代码了，利用Hibernate自动建表、插入和更新自不用说，因为所有Model从特定类继承而来，丰富的API基本够平常所需，而且查询接口十分简单和强大。再也不用像SpringMVC那样每一个Model都要建一个Dao，每一个查询都要写一个十分复杂的Hibernate方法。

      Play框架已经不仅仅是个框架的概念了，而是一个开发环境了，因为要利用它帮你生成Project，eclipsify进入开发模式，run进入debug模式，war进入发布模式，而且Play自定义了一套Project下的目录结构和文件名称，这些一经修改很有可能运行就会出错。这是一把双刃剑，虽然方便了开发者和初学者，但是对于比较喜欢自己完全掌控代码和框架运作的开发人员来说并不是一件好的事情。

      当然，也感觉Play有些还不太习惯的地方，较之其他框架另类之处，还有一些有待改善的地方。

      • 包结构名默认被限定，不符合大众模式（域名倒置的形式）
      • 一个Controller不能自定义对应的Template的目录名，而默认采用与Controller名一致的目录名（强烈建议应该在Controller上加一个Annotation来自定义Template的目录名）
      • View模式下的模板语法（Groovy）据说效率比较低
      • 开发模式下，因为靠Play自带程序运行，脱离IDE环境，较难实现单步跟踪
      • 相比Spring，加入其它第三方组件不太方便，比如更换模板引擎等
      总的来说，Play让人耳目一新的感觉，第一感觉是非常棒的，真的大大加快了用Java开发Web的速度和效率，而且Play作为框架的理念也理解的很好很懂得开发人员的心思来尽量满足需求，当然个人觉得这甚至有点过了因为什么都帮你干完了开发人员的价值很多就体现不出来了。作为一个demo或者小型应用，Play绝对适合，但是要开发一个企业级大项目，就至今对Play的了解来看，也许Spring这一套路更稳重一些。

      看看 Play , Spring , 框架

      看看 Java