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. 阅读全文 >>
概述
当使用基于 JSON 库的 typeclass(Unmi: typeclass 还没摸准翻译成什么词较合适，此前译作 类型类，觉得有点不妥，所以暂时保留原样) 时，可能会把泛型支持包含进这些 typeclass 中来. 针对基于终端控制查询参数，使用基本的结构作为查询结果的 REST API 来说可能是一个很好的应用方式.
Scala 对泛型的支持
给定如下基本的结构作为搜索结果:
|
1 2 3 4 5 6 |
case class SearchResults[T]( elements: List[T], page: Int, pageSize: Int, total :Int ) |
Unmi 注: 上面 case class 涉及到了 Scala 的样本类的特性，Scala 会给这个类自动添加一些句法：1）添加与类名一致的工厂方法，2）参数列表中的所有参数前隐式获得了 val 前缀，即会由相应的的实例变量保持状态，3）自动添加了 toString, hashCode, 和 equals 方法。 阅读全文 >>
处理 JSON 请求
JSON 请求是一个以有效的 JSON 数据作为请求体的 HTTP 请求. 它必须指定 Content-Type 头为 text/json 或是 application/json 作为 mime 类型.
默认的， Action 使用 any content 作为 Body 解析器, 这让你接收 Body 并解析为 JSON (实际为 JsValue):
|
1 2 3 4 5 6 7 8 9 10 11 |
def sayHello = Action { request => request.body.asJson.map { json => (json \ "name").asOpt[String].map { name => Ok("Hello " + name) }.getOrElse { BadRequest("Missing parameter [name]") } }.getOrElse { BadRequest("Expecting Json data") } } |
更好的(也是更简单的)办法是指定你自己的 BodyParser 用以告诉 Play 把类容 Body 直接解析为 JSON: 阅读全文 >>
概述
推荐的处理 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. 阅读全文 >>
前一篇介绍了 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: 阅读全文 >>
Windows 命令行 cmd 窗口系统默认的大小(80*40)对于现在的屏幕配置已经跟不上时代了，我们总是要把它改大些，而且缓冲区大小也想改得大大的。单纯的为当前的 Windows 命令行窗口修改显示大小和缓冲区大小就简单了，右键命令行窗口标题，属性里改屏幕缓冲区和窗口大小就是，系统会为与当前标题相同的命令行窗口记住你的设置，比如 C:\Windows\system32\cmd.exe。但是经常你又会打开不同标题的命令行窗口，如 Tomat，这时候它又是默认的 80*40 的窗口大小，又得改，再碰不同标题又要改。
于是能否直接修改系统默认的 cmd 窗口和它的缓冲区大小呢，以后碰到新的标题就参考于它。行的，方法是改注册表。
先来看下你可以在命令行下直接指定命令行窗口的大小了，进到命令行执行 mode，可以看到关于控制台的信息如下：
Status for device CON:
----------------------
Lines: 2000
Columns: 120 阅读全文 >>
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 类，例如有这样一个代码： 阅读全文 >>
寻求了很久关于如何在 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，用 @ 符号： 阅读全文 >>
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
不过没找到源码，其实自己写一个 OrderedProperties 也不难，并不需要重头写起，只要继承自 Properties，覆盖原来的 put/keys,keySet,stringPropertyNames 即可，其中用一个 LinkedHashSet 来保存它的所有 key。完整代码如下： 阅读全文 >>
模板, 实际作为简单函数存在的, 它可以任何你希望的方式被组合应用. 下面是一些通用场景的使用案例.
布局
我们来声明一个 views/main.scala.html 模板来用作主布局模板:
|
1 2 3 4 5 6 7 8 9 10 |
@(title: String)(content: Html) <!DOCTYPE html> <html> <head> <title>@title</title> </head> <body> <section class="content">@content</section> </body> </html> |
正如你所看到的, 这个模板有两个参数: 一个标题和一个 HTML 内容块. 现在我们可在另一个模板 views/Application/index.scala.html 中用它: 阅读全文 >>