- 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. Read More
概述
当使用基于 JSON 库的 typeclass(Unmi: typeclass 还没摸准翻译成什么词较合适,此前译作 类型类,觉得有点不妥,所以暂时保留原样) 时,可能会把泛型支持包含进这些 typeclass 中来. 针对基于终端控制查询参数,使用基本的结构作为查询结果的 REST API 来说可能是一个很好的应用方式.
Scala 对泛型的支持
给定如下基本的结构作为搜索结果:1case class SearchResults[T]( 2 elements: List[T], 3 page: Int, 4 pageSize: Int, 5 total :Int 6)
Unmi 注: 上面 case class 涉及到了 Scala 的样本类的特性,Scala 会给这个类自动添加一些句法:1)添加与类名一致的工厂方法,2)参数列表中的所有参数前隐式获得了 val 前缀,即会由相应的的实例变量保持状态,3)自动添加了 toString, hashCode, 和 equals 方法。 Read More
处理 JSON 请求
JSON 请求是一个以有效的 JSON 数据作为请求体的 HTTP 请求. 它必须指定Content-Type头为text/json或是application/json作为 mime 类型.
默认的,Action使用 any content 作为 Body 解析器, 这让你接收 Body 并解析为 JSON (实际为JsValue):1def sayHello = Action { request => 2 request.body.asJson.map { json => 3 (json \ "name").asOpt[String].map { name => 4 Ok("Hello " + name) 5 }.getOrElse { 6 BadRequest("Missing parameter [name]") 7 } 8 }.getOrElse { 9 BadRequest("Expecting Json data") 10 } 11}
更好的(也是更简单的)办法是指定你自己的BodyParser用以告诉 Play 把类容 Body 直接解析为 JSON: Read More
概述
推荐的处理 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. Read More- 前一篇介绍了 JavaDoc 编程,书写自定义的 Taglet 支持 @unmi 等, 那时提到了 Doclet,但是差点无视了 Doclet,现在才知道 Doclet 真是太强大了,有了它你会觉得 javadoc 已经不是原本的那个 javadoc 了,别再把 javadoc 看作只会生成一大堆 HTML 文件的工具了。尤其是搭配上自定义的 Taglet,那可是,自已体验吧。
Doclet 是 JavaDoc 的一个很隆重的扩展点,可以在执行 javadoc 时用 -doclet 来指定自己的 Doclet,那么 doclet 可以为我们做些什么呢?
可以为我们生成 HTML 的 JavaDoc API 文档,这就是默认的 com.sun.tools.doclets.standard.Standard 为我们做的事,还可以像以前那样从源文件中抽取信息生成各种 XML 文件,或是 PDF, Excel, UML 图等等任何可能的内容,或做任何有作为的事情。总之在 doclet 中可以感知道对任何包,类,方法,字段等的遍历。这里 Doclet.com 有大量的第三方的 doclet 供你选择,如:
AntDoclet, API Guide Doclet, EJBGen, Java2Rose Doclet, JDiff, JUnitDoclet, LaTeXtaglet, PDFDoclet, PublishedApiDoclet, ServletDoclet, Spell Check Doclet, UMLGraph, VelocityDoclet, XDoclet, xml-doclet 等数十种 Doclet, 还可以找到别的,所以你要是不想自定义 Doclet 的话,有第三方可用就直接用人家的就行。
总有特殊需求的时候,总有要自定义 Doclet 的时候。说那么多总要来看看 Doclet 可以用来做什么,见如下 DocumentDoclet: Read More - Windows 命令行 cmd 窗口系统默认的大小(80*40)对于现在的屏幕配置已经跟不上时代了,我们总是要把它改大些,而且缓冲区大小也想改得大大的。单纯的为当前的 Windows 命令行窗口修改显示大小和缓冲区大小就简单了,右键命令行窗口标题,属性里改屏幕缓冲区和窗口大小就是,系统会为与当前标题相同的命令行窗口记住你的设置,比如 C:\Windows\system32\cmd.exe。但是经常你又会打开不同标题的命令行窗口,如 Tomat,这时候它又是默认的 80*40 的窗口大小,又得改,再碰不同标题又要改。
于是能否直接修改系统默认的 cmd 窗口和它的缓冲区大小呢,以后碰到新的标题就参考于它。行的,方法是改注册表。
先来看下你可以在命令行下直接指定命令行窗口的大小了,进到命令行执行 mode,可以看到关于控制台的信息如下:
Status for device CON:
----------------------
Lines: 2000
Columns: 120 Read More - javadoc 可为我们的 Java 项目生成 API 文档,别人的应该是看得多了,自己的可能不好意思晾出来看。那 Java 源代码里的 @author, @see, @param 等应该是司空见惯了吧。除此之外我们还可以自定义自己的 tag,并让它们的内容按照我们需要的格式生成到 javadoc 文档中,或作他用。还记得没有 Maven 的时代我们是怎样用 XDoclet 生映射文件的吗?现在的 Taglet 定制想要做的事情大抵如此。
执行一下 javadoc 命令看看,一堆的参数可以指定,又有学问在里头,且看:
-tag <name>:<locations>:<header> Specify single argument custom tags
-taglet The fully qualified name of Taglet to register
-tagletpath The path to Taglets
和
-doclet <class> Generate output via alternate doclet
-docletpath <path> Specify where to find doclet class files
关于 doclet 部份这儿暂且不说,单讲 tag 部分的东西。
对于自定义 tag,简单的时候,用参数 -tag 都可以不写自己的 taglet 类,例如有这样一个代码: Read More - 寻求了很久关于如何在 Java 中实现多行字符串,即 Here Document。因为在测试中准备大的字符串数据是不得不用加号去拼接,甚至是麻烦。稍好就是用 http://www.htmlescape.net/javaescape_tool.html 把你输入的大段文字生成 Java 的字符串。
找过一些介绍 Java 实现 Here Document 的方法,首先大家无一不是把这个多行字符串塞在注释里,有些实现在运行还在依赖于 Java 源文件中的注释,这不太可取。聪明的做法应该要去打编译器的主意,让编译后体现在 Class 文件中,变量就被赋上了多行字符串值,这就是 JDK1.5 引入的 APT(Annotation Processing Tool),到 JDK1.6 后可操作性更强了,可以 javac 的时候带上 -processor 参数。
单单从语法特性上来讲,我觉得 Java 与现今流行的语言还是有差距,不过它一直在成长,像 JDK 1.5 和 1.7 这两个版本就带来了不少好东西。想要见识一下其他些个语言,如 Perl, PHP, Ruby, C++11 怎么实现 Here Document 还是请看 http://en.wikipedia.org/wiki/Here_document。
就连 Java 最亲密的战友 C# 都早实现了 Here Document,用 @ 符号: Read More - Java 的 Properties 加载属性文件后是无法保证输出的顺序与文件中一致的,因为 Properties 是继承自 Hashtable 的, key/value 都是直接存在 Hashtable 中的,而 Hashtable 是不保证进出顺序的。
总有时候会有关心顺序一致的需求,恰如有 org.apache.commons.collections.OrderdMap(其实用 LinkedHashMap 就是保证顺序) 一样,我们也想要有个 OrderdProperties。网上查了下还真有:
http://livedocs.adobe.com/jrun/4/javadocs/jrunx/util/OrderedProperties.html
http://www.openrdf.org/doc/alibaba/2.0-rc4/apidocs/org/openrdf/repository/object/composition/helpers/OrderedProperties.html
不过没找到源码,其实自己写一个 OrderedProperties 也不难,并不需要重头写起,只要继承自 Properties,覆盖原来的 put/keys,keySet,stringPropertyNames 即可,其中用一个 LinkedHashSet 来保存它的所有 key。完整代码如下: Read More - 模板引擎
模板, 实际作为简单函数存在的, 它可以任何你希望的方式被组合应用. 下面是一些通用场景的使用案例.
布局
我们来声明一个views/main.scala.html模板来用作主布局模板:1@(title: String)(content: Html) 2<!DOCTYPE html> 3<html> 4 <head> 5 <title>@title</title> 6 </head> 7 <body> 8 <section class="content">@content</section> 9 </body> 10</html>
正如你所看到的, 这个模板有两个参数: 一个标题和一个 HTML 内容块. 现在我们可在另一个模板views/Application/index.scala.html中用它: Read More