Groovyでメソッドの引数に型を指定する意味

強い動的型付け言語であるGroovy。
JVM上で動く言語でありながら、まるでPHPの様にサクサクコーディングが出来る素敵な言語です。
強い動的型付けである為、型の宣言をする必要が無く、ソースがスッキリします。
ただし、PHP等のスクリプト言語における動的型付けと少し異なるのが、
ただし型の宣言は省略出来るのであって、宣言出来ない訳ではありません。つまり、
「型の指定はしなくても良いけど、する事も出来る」
という訳です。
じゃあ型を指定する場合は一体何が嬉しいの？という点を今回纏めてみました。
以下早速サンプルソースです。動的型付け言語の特徴として、コンパイル時点ではなく、実行時点でなければエラーの検出が出来ないという特徴を活かして説明しています。
*2012/02/12 追記：PHPでは仮引数でクラスやインタフェースを指定する事が出来ます。

型を指定しない場合

def test(a){

println a;

a = a.toLong() //Stringが渡されるとこの時点で例外が発生

println a.getClass()

}

test(1)

test("a")

以下、コンパイルと実行

[koji:groovy]$ groovyc type_check.groovy
[koji:groovy]$ groovy type_check
1
class java.lang.Long
a
Caught: java.lang.NumberFormatException: For input string: "a"
java.lang.NumberFormatException: For input string: "a"
at type_check.test(type_check.groovy:4)
at type_check$test.callCurrent(Unknown Source)
at type_check.run(type_check.groovy:10)

test(1)は問題なく実行され、test("a")はメソッドの途中まで実行されて、toLong()を実行するタイミングで例外が発生しています。

コレはString型にはtoLong()メソッドが存在しない為です。

型を指定する場合

def test(Integer a){
        println a;
        a = a.toLong()
        println a.getClass()
}

test(1)
test("a") //そもそもStringをとるtestメソッドが存在しないのでこの時点で例外が発生

以下、コンパイルと実行

[koji:groovy]$ groovyc type_check.groovy
[koji:groovy]$ groovy type_check
1
class java.lang.Integer
Caught: groovy.lang.MissingMethodException: No signature of method: type_check.test() is applicable for argument types: (java.lang.String) values: [a]
Possible solutions: test(java.lang.Integer), getAt(java.lang.String), wait(), use([Ljava.lang.Object;), wait(long), is(java.lang.Object)
groovy.lang.MissingMethodException: No signature of method: type_check.test() is applicable for argument types: (java.lang.String) values: [a]
Possible solutions: test(java.lang.Integer), getAt(java.lang.String), wait(), use([Ljava.lang.Object;), wait(long), is(java.lang.Object)
at type_check.run(type_check.groovy:10)
[koji:groovy]$

test(1)は問題なく実行されていますが、こちらの場合はtest("a")を実行したタイミングで例外が発生しています。
コレはtest()というメソッド名でStringを受け取るメソッドが存在しないために発生しているエラーです。

ざっくりまとめると、
前者の場合：PHP等の動的型付けなスクリプト言語では一般的なパターン
後者の場合：Java等の静的型付けなお固い言語では一般的なパターン
となります。

ただし注意しなければ成らないのが、後者の場合でもGroovyのコンパイルでは型チェックが出来ないという事です。プログラムが実行され、該当箇所が実際に実行されるまでエラーになるかどうか分かりません。
コレはGroovyが動的型付け言語であるためです。（型チェックが出来ないのは前者も同様）
例えば、以下のように後者のパターンの実行方法を変えた場合にはエラーは発生しません。

test(1)
if( 0 ) {
        test("a")  //ここは実行されないからプログラム的にはエラー無し
}

じゃあ態々メソッドの引数に型の指定をしてもメリット無いじゃないかと思われるかもしれませんが、当然メリットもあります。

まず、型を指定しておくと実行時例外にはなるものの、メソッドの中身は実行されないため、渡された引数が本当に意図した型なのかという事をメソッドの中で一々チェックしなてくても良い点。

2点目が、Groovyで作成したライブラリなどをJavaで利用する時。Groovyのソース上で型を指定しておくとJava側で意図しない値（今回の例であればString）を渡すようなプログラムを書いた場合、Javaのコンパイル時点でその誤りを検出出来ます。

Groovyでメソッドの引数に型を指定しない場合の前者、型を指定した場合の後者のjavapは以下のようになります。（該当メソッド部分のみ抽出）

前者の場合

[koji:groovy]$ javap type_check | grep test
  public java.lang.Object test(java.lang.Object);

後者の場合

[koji:groovy]$ javap type_check | grep test
  public java.lang.Object test(java.lang.Integer);

どういった場合に型を指定するかはプログラマや状況によるとは思いますが、基本的には仮引数に関しては型を指定してあげた方が良いと思います。

Groovyで日時の取り扱いサンプル（Dateオブジェクト）

Groovyが楽しい！
という事で、早速Dateオブジェクトのサンプルを書いてみました。
Scalaはちょっとお休みして今年はGroovyを勉強しようかなと思っています。

PHPのタイムゾーン（時差の計算）についての備忘録

今まで全くタイゾーンについて意識していませんでしたが、実際に自分が外国に来てからいざ
Webアプリケーションを作ってみようと思った段階で、「あれ？日付の取り扱いってどうすれば良いんだ？」と疑問に思ったので、この際なので纏めてみました。ちなみにPHPです。

GMTとUTC

基本的に同じ物です。GMTはよくグリニッジ天文台が云々言われるヤツですね。
詳しい違いは調べて頂ければ分かると思います。
基本的にUTCの方が正確な物というイメージですので、PHPプログラム内ではUTCを使用するようにした方が良いと思われます。

時差について

世界中の国々では当然時差があります。
例えば日本が24:00の場合、冬期ならばドイツは前日の16:00となります。
ちなみにドイツにはサマータイムがあるので、夏場だと時差が7時間となります。 この時点でプログラムで態々計算するのが面倒臭そうだというのが想像出来ると思います。

PHPでどのように取り扱うか

PHP5.2からDateTimeという組み込みクラスが使えるようになっています。
いきなり結論ですが、こいつを使えば全ての問題が解決します。
時差の計算などは全てこのクラスに任せればOKなのです。

実際の使い方は以下。

date_default_timezone_set('UTC');
$t = new DateTime("2012-11-05 21:34:40.0000000");

$t->setTimeZone( new DateTimeZone('UTC'));
echo $t->format(DateTime::ISO8601), "(UTC)<br />";

$t->setTimeZone( new DateTimeZone('Asia/Tokyo'));
echo $t->format(DateTime::ISO8601), "(Tokyo)<br />";

$t->setTimeZone( new DateTimeZone('Europe/Berlin'));
echo $t->format(DateTime::ISO8601), "(Berlin)<br />";

実行すると以下のようになります。

2012-11-05T21:34:40+0000(UTC)
2012-11-06T06:34:40+0900(Tokyo)
2012-11-05T22:34:40+0100(Berlin)

簡単なソースですので見れば分かると思いますが、大まかな流れは、
1.タイムゾーンをセット（これはphp.iniでもOK）
2.DateTimeオブジェクトを生成
3.DateTimeオブジェクトのタイムゾーンを変更する
4.formatメソッドを使って時刻を表示する。

今回の場合、タイムゾーンに世界標準時間（UTC）を指定しているので、DateTimeオブジェクトのコンストラクタに渡してあげた時刻文字列は、世界標準時間として扱われます。
以降、生成したDateTImeオブジェクトのタイムゾーンを変更すると、世界標準時間（UTC）からの時差を求める事が出来ます。

「じゃあタイムゾーンに東京とか指定してDateTimeオブジェクト生成するとどうなるんだ？
元々日本国内で運営していたサービスを世界展開する場合、データベースなどに保存されている日時は日本時間だぞ？それをUTCとして扱うとおかしくなるんじゃないの？」
という疑問が当然出てくると思います。
その点に付いては、下記の「注意点」を参照してください。

*なお、php.iniかスクリプト内でタイムゾーンを設定していないと以下のようなエラーが出ます。

Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct() [<a href='datetime.--construct'>datetime.--construct</a>]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead' in /Users/koji/Sites/flash_cards/hoge.php:3 Stack trace: #0 /Users/koji/Sites/flash_cards/hoge.php(3): DateTime->__construct('2012-11-05 21:3...') #1 {main} thrown in /Users/koji/Sites/flash_cards/hoge.php on line 3

注意点

上記の方法では、既に生成したDateTimeオブジェクトのタイムゾーンを変更する事で、時差を求めています。
言い方を変えると、DateTimeオブジェクトを生成した時のタイムゾーンを元に時差を求めている事になります。

例えば、タイムゾーンを東京としてDateTimeオブジェクトを生成したとします。
で、そのDateTimeオブジェクトからUTC（世界標準時間）を求めた場合、当然のごとくその時間から-9時間となります。

// DateTimeオブジェクトをタイムゾーンをUTCとして生成
date_default_timezone_set('UTC');
$t = new DateTime("2012-11-05 21:34:40.0000000");

$t->setTimeZone( new DateTimeZone('UTC'));
echo $t->format(DateTime::ISO8601), "(UTC)<br />";

$t->setTimeZone( new DateTimeZone('Asia/Tokyo'));
echo $t->format(DateTime::ISO8601), "(Tokyo)<br />";

$t->setTimeZone( new DateTimeZone('Europe/Berlin'));
echo $t->format(DateTime::ISO8601), "(Berlin)<br />";

echo "-----------------------------------------------";

// DateTimeオブジェクトをタイムゾーンをTokyoとして生成
date_default_timezone_set('Asia/Tokyo');
$t = new DateTime("2012-11-05 21:34:40.0000000");

$t->setTimeZone( new DateTimeZone('UTC'));
echo $t->format(DateTime::ISO8601), "(UTC)<br />";

$t->setTimeZone( new DateTimeZone('Asia/Tokyo'));
echo $t->format(DateTime::ISO8601), "(Tokyo)<br />";

$t->setTimeZone( new DateTimeZone('Europe/Berlin'));
echo $t->format(DateTime::ISO8601), "(Berlin)<br />";

実行結果は以下

2012-11-05T21:34:40+0000(UTC)
2012-11-06T06:34:40+0900(Tokyo)
2012-11-05T22:34:40+0100(Berlin)
-----------------------------------------------
2012-11-05T12:34:40+0000(UTC)
2012-11-05T21:34:40+0900(Tokyo)
2012-11-05T13:34:40+0100(Berlin)

同じ時刻でDateTimeを生成しているのに、結果が全く異なっていますね。
冷静に考えればそのままなのですが、あくまでDateTimeオブジェクトを生成した時のタイムゾーンを元に時刻が計算される、という事を覚えておかないとはまってしまいます。
なお、DateTimeオブジェクトを生成する際にコンストラクタに渡している文字列の時刻ですが、これはPostgreSQLのTimestamp型からPDOでSELECTした結果の文字列です。

また、DateTimeに渡す文字列の時刻ですが、UNIXタイムスタンプや、今回のサンプル実行結果のようなタイムゾーン付きの文字列( 2012-11-05T21:34:40+0900 <-こんなやつ）の場合には、コンストラクタに渡すタイムゾーンパラメータや現在のタイムゾーンは無視されてしまいます。

// DateTimeオブジェクトをタイムゾーンをTokyoとして生成
// でも、DateTimeコンストラクタにタイムゾーン付き時刻の文字列を渡すと、その時刻のみを元にDateTimeオブジェクトが生成される
date_default_timezone_set('Asia/Tokyo');
$t = new DateTime("2012-11-01T13:34:40+0100");

$t->setTimeZone( new DateTimeZone('UTC'));
echo $t->format(DateTime::ISO8601), "(UTC)<br />";

$t->setTimeZone( new DateTimeZone('Asia/Tokyo'));
echo $t->format(DateTime::ISO8601), "(Tokyo)<br />";

$t->setTimeZone( new DateTimeZone('Europe/Berlin'));
echo $t->format(DateTime::ISO8601), "(Berlin)<br />";

実行結果

2012-11-01T12:34:40+0000(UTC)
2012-11-01T21:34:40+0900(Tokyo)
2012-11-01T13:34:40+0100(Berlin)

参考URL

http://php.net/manual/ja/class.datetime.php
http://www.php.net/manual/ja/datetime.construct.php
http://www.php.net/manual/ja/class.datetimezone.php
http://www.php.net/manual/ja/datetime.formats.php
http://php.net/manual/ja/function.date-default-timezone-set.php

Play framework 2.0のScalaテンプレートのユースケース意訳

Play framework2.0のScala templates common use casesを意訳しました。

先日テンプレートのシンタックス系のマニュアルを意訳しましたが、こちらはもう少し具体的にScalaテンプレートの使い方を説明しているものになります。

例のごとく、もし私の訳が間違っていても責任は負えませんのであしからず・・・
正確なものを読みたい方は原典をどうぞ。

http://www.playframework.org/documentation/2.0.1/ScalaTemplateUseCases

なお、日本Playframeworkユーザー会さんの方で翻訳作業が進行中のようですので、そちらを待たれるという手もあります。

それではどうぞ！

Scalaテンプレートの一般的なユースケース

テンプレートというシンプルな機能は、あなたがやりたい方法で構成することが出来ます。
以下に、いくつかの一般的なシナリオを示します。

レイアウト

メインのレイアウトテンプレートとして機能するviews/main.scala.htmlを宣言しましょう。

@(title: String)(content: Html)
<!DOCTYPE html>
<html>
  <head>
    <title>@title</title>
  </head>
  <body>
    <section class="content">@content</section>
  </body>
</html>

ご覧のとおり、このテンプレートは2つのパラメータを必要としています。
タイトルと、HTMLコンテンツです。
では、別のテンプレートであるviews/Application/index.scala.htmlからこのテンプレートを使ってみましょう。

@main(title = "Home") {
    
  <h1>Home page</h1>
    
}

Note：本ドキュメントでは、時々@main("Home")ではなく、@main(title = "Home")という形で、名前付き引数を使用します。
こうすることで、ソースをパッと見ただけで影響範囲がとても明確になります。

時々、サイドバーやパンくずリストといった個別のパーツが必要になるでしょう。
これは、パラメタを追加することで実現できます

@(title: String)(sidebar: Html)(content: Html)
<!DOCTYPE html>
<html>
  <head>
    <title>@title</title>
  </head>
  <body>
    <section class="sidebar">@sidebar</section>
    <section class="content">@content</section>
  </body>
</html>

このパラメタを追加したメインテンプレートを、さっき用意したviews/Application/index.scala.htmlから使ってみましょう。

@main("Home") {
  <h1>Sidebar</h1>

} {
  <h1>Home page</h1>

}

また、サイドバーの部分を別々に宣言することもできます。

@sidebar = {
  <h1>Sidebar</h1>
}

@main("Home")(sidebar) {
  <h1>Home page</h1>

}

※注意（公式にない私的メモ）
Play frameworkにおけるScalaテンプレートは関数だということを思い出しましょう。
さらに、テンプレートパラメータ（main.scala.htmlの先頭で宣言されている引数を受け取る部分）は、カリー化された関数になります。
だから、index.scala.htmlから呼び出す際に、コードブロックを{}で囲んで渡してあげることができるわけです。
カリー化されたmain.scala.htmlの方の引数の型が、Html型になっているので、コードブロックとして渡したHTMLはHtml型になるっぽいです。

タグ（これらは関数、でしょ？）

それでは、ちょっとしたインフォメーションを表示するシンプルなタグをviews/tags/notice.scala.htmlに書いてみましょう。

@(level: String = "error")(body: (String) => Html)
 
@level match {
    
  case "success" => {
    <p class="success">
      @body("green")
    </p>
  }

  case "warning" => {
    <p class="warning">
      @body("orange")
    </p>
  }

  case "error" => {
    <p class="error">
      @body("red")
    </p>
  }
    
}

これを別のテンプレートから呼び出してみましょう。

@import tags._
 
@notice("error") { color =>
  Oops, something is <span style="color:@color">wrong</span>
}

※注意（公式にない私的メモ）
テンプレートの方に@import tags._っていきなり出ていますね。
何の説明もなく、さも当たり前に書かれているので、なんじゃこりゃ！？と思いましたが、よくよく考えるとScalaテンプレートは結局ただの関数なので、上記で作成したviews/tags/notice.scala.htmlが、tags.notics()になっているということなんですね。（たぶん）

Includes

再度言いますが、特別なことは何もありません。
どんなテンプレートもどこからでも呼び出すことが出来ます。
普通の関数だってどこかから呼び出しているのと全く変わりありません。

<h1>Home</h1>
 
<div id="side">
  @common.sideBar()
</div>

moreScriptsとmoreStylesと同等の事

Play framework1.xの頃のmoreScriptsやmoreStylesと同じ環境をScalaテンプレートで宣言するには、mainテンプレートの以下のように宣言します。

(title: String, scripts: Html = Html(""))(content: Html)

<!DOCTYPE html>

<html>
    <head>
        <title>@title</title>
        <link rel="stylesheet" media="screen" href="@routes.Assets.at("stylesheets/main.css")">
        <link rel="shortcut icon" type="image/png" href="@routes.Assets.at("images/favicon.png")">
        <script src="@routes.Assets.at("javascripts/jquery-1.7.1.min.js")" type="text/javascript"></script>
        @scripts
    </head>
    <body>
        <div class="navbar navbar-fixed-top">
            <div class="navbar-inner">
                <div class="container">
                    <a class="brand" href="#">Movies</a>
                </div>
            </div>
        </div>
        <div class="container">
            @content
        </div>
    </body>
</html>

mainテンプレート以外のテンプレートでのみ使いたいJavaScriptなどは以下のように定義します。

@scripts = {
    <script type="text/javascript">alert("hello !");</script>
}

@main("Title",scripts){

   Html content here ...

}

mainテンプレートに渡すべき特別なJavaScriptなどが無い場合は、以下のよう呼び出します。

@main("Title"){

   Html content here ...

}

※注意（公式にない私的メモ）
mainテンプレートのscripts引数を見てみると、デフォルト引数としてHtml=("")がセットされていますよね？
だから、mainテンプレートを呼び出す、別のテンプレートからscriptsを渡さなければ自動的にHtml("")がscriptsに格納されるわけですね。

以上で終了です。

Play framework 2.0のフォームの制御部分意訳

Play framework2.0のHandling form submissionを意訳しました。

ざっと概要を言うと、ブラウザから送られてくるフォームのデータを、どうやってScalaの値にマッピングするのか、ということです。
マッピングの前に、どうやって値を取得するんだ？という疑問もありますが、あまり深く考えずに取得できるようになっています。
言い方を変えると、マッピングする部分を書けば、後はPlayがうまいこと値をrequestから引っ張ってきてくれるということです。

ただ、Play frameworkらしからぬ感じなのですが、具体的なサンプルが少なくて、ちょっとマニュアルが分かりづらかったです。（私の諸々のスキルが低いというのもありますが）
なので、途中でサンプルソースを載せました。（背景が紫色の部分）

例のごとく、もし私の訳が間違っていても責任は負えませんのであしからず・・・
正確なものを読みたい方は原典をどうぞ。

http://www.playframework.org/documentation/2.0.1/ScalaForms

なお、日本Playframeworkユーザー会さんの方で翻訳作業が進行中のようですので、そちらを待たれるという手もあります。

それではどうぞ！

フォームの定義

play.api.dataパッケージは、HTTPフォームのデータを扱い、バリデーションも扱うヘルパーが含まれています。
フォームを扱う最も簡単な方法は、play.api.data.Form構造を定義することです。

import play.api.data._
import play.api.data.Forms._

val loginForm = Form(
  tuple(
    "email" -> text,
    "password" -> text
  )
)

以下のフォームは、結果としてMap[String,String]から、(String, String)の値を生成します。

val anyData = Map("email" -> "bob@gmail.com", "password" -> "secret")
val (user, password) = loginForm.bind(anyData).get

もし、requestスコープの中のソースをコーディングしている場合であれば、直接requestの中身をバインドすることが出来ます。

val (user, password) = loginForm.bindFromRequest.get

複雑なオブジェクトの構築

formは値を構築・分解する機能を使用することが出来ます。
例えば、既存のケースクラスにラップすることが出来ます。

import play.api.data._
import play.api.data.Forms._

case class User(name: String, age: Int)

val userForm = Form(
  mapping(
    "name" -> text,
    "age" -> number
  )(User.apply)(User.unapply)
)

val anyData = Map("name" -> "bob", "age" -> "18")
val user: User = userForm.bind(anyData).get

Note：tupleとmappingを使用することによる違いは、tupleを使用する場合、constructionとdeconstructionを定義する必要が無いということです。
（だって私たちはtupleの構築と分解方法を知っていますよね？）

mapping関数は、あなたに、あなたのカスタマイズされた関数を定義させます。
ケースクラスを構築したり分解したりしたい場合はデフォルトのapplyメソッドとunapplyメソッドを使用するだけです。

※注意（公式にない私的メモ）
ここの訳は良く分からない。
construction and deconstruction functionsをいったいなんと訳せばいいのか・・・

もちろん、Formシグネチャがケースクラスに正確に一致しないことも良くあります。
例として、利用規約に同意するために使われるチェックボックスを含んだformを使ってみましょう。
Userに値を与える必要はありません。
これはフォームのバリデーションに一度使用されますが、役に立つ情報を教えてくれないダミーのフィールドです。
私たちは自分自身の構築・分解のための機能を定義できるので、これを扱うのはとても簡単です。

val userForm = Form(
  mapping(
    "name" -> text,
    "age" -> number,
    "accept" -> checked("Please accept the terms and conditions")
  )((name, age, _) => User(name, age))
   ((user: User) => Some((user.name, user.age, false))
)

Note：formに既存のUserを代入したとき、deconstructionが使用されています。
これは、Userをデータベースからロードして、それを更新するためにフォームを用意する場合に便利です。

制約の定義

それぞれのmappingで、バインディングの過程で値をチェックする、追加のバリデーションの制約を定義することが出来ます。

import play.api.data._
import play.api.data.Forms._
import play.api.data.validation.Constraints._

case class User(name: String, age: Int)

val userForm = Form(
  mapping(
    "name" -> text.verifying(required),
    "age" -> number.verifying(min(0), max(100))
  )(User.apply)(User.unapply)
)

Note：こういう書き方もできます

mapping(
  "name" -> nonEmptyText,
  "age" -> number(min=0, max=100)
)

このconstructsは上の例と全く同じ制約になります。

また、フィールドにアドホックな制約を定義することもできます。

val loginForm = Form(
  tuple(
    "email" -> nonEmptyText,
    "password" -> text
  ) verifying("Invalid user name or password", fields => fields match { 
      case (e, p) => User.authenticate(e,p).isDefined 
  })
)

バインディングのエラーを制御する

制約を定義した場合には、バインディング時のエラーを制御できるようにする必要があります。
以下のように、foldを使うことが出来ます。

loginForm.bindFromRequest.fold(
  formWithErrors => // binding failure, you retrieve the form containing errors,
  value => // binding success, you get the actual value 
)

※注意（公式にない私的メモ）
実際のサンプルはこんな感じ

def debug = Action { implicit request =>
    // ************************************************************
    // フォームの定義
    // ************************************************************
    // nonEmptyTextやnumberといったプロパティ（とメソッド）はplay.api.data.Formsクラスの中
    val myForm = Form(
        tuple(
            "val1" -> nonEmptyText,
            "val2" -> number
        )
    )
    
    
    // ************************************************************
    // request（POSTされたデータ）を取得する（2パターン）
    // ************************************************************
    /**
     * 最もシンプルなフォームの値の取得方法
     * フォームの定義で 制約（constraints）を指定している値で、実際のフォームに値が
     * 入力されていない場合、この取得方法だと以下のエラーが発生する
     * [NoSuchElementException: None.get]
     * フォームの定義で制約を付けている場合は、必ずfoldを使ってエラーハンドリングをすること！
     * 値が入力されている場合は正常に動いてしまうので、正常系のテストでは問題なく
     * 動作してしまう為、注意すること。
     */
    val(val1, val2) = myForm.bindFromRequest.get
    Ok("bindFormRequest.get" + " -> " + (val1 + 1) + " : " +  (val2 + 1))
    
    
    /**
     * フォームの定義に制約を指定している場合は、foldを使って必ずエラーハンドリングするように！
     * 問題ない場合はタプルとして値が取得でき、型の制約も特に問題なく動作する
     */
    myForm.bindFromRequest.fold(
        errors => Ok("NOOOOO"),
        value => Ok("bindFormRequest.fold" + " -> " + (value._1 + 1) + " : " + (value._2 + 1))
    )
}

formをデフォルト値で初期化する

時々データを編集するために、formに既存のデータを代入したいこともあるでしょう。その場合は以下のようにします。

val filledForm = userForm.fill(User("Bob", 18))

ネストされた値

formのmappingでは、ネストされた値を定義することもできます。

case class User(name: String, address: Address)
case class Address(street: String, city: String)

val userForm = Form(
  mapping(
    "name" -> text,
    "address" -> mapping(
        "street" -> text,
        "city" -> text
    )(Address.apply)(Address.unapply)
  )(User.apply, User.unapply)
)

この方法でネストされたデータを使用する場合、ブラウザから送られるフォームの値は「address.street, address.city, etc」の様な命名にしなければなりません。

繰り返される値

formのmappingでは、繰り返される値（同名の複数の値）を定義することもできます。

case class User(name: String, emails: List[String])

val userForm = Form(
  mapping(
    "name" -> text,
    "emails" -> list(text)
  )(User.apply, User.unapply)
)

このような繰り返される値を使用する場合、ブラウザから送られるフォームの値は「emails[0], emails[1], emails[2], etc」のような命名にしなければなりません。

Optionな値

formのmappingでは、Optionな値を定義することもできます。

case class User(name: String, email: Option[String])

val userForm = Form(
  mapping(
    "name" -> text,
    "email" -> optional(text)
  )(User.apply, User.unapply)
)

Note：emailフィールドは、requestの中に存在しない場合と、ブランク値が入っている場合には、Noneがセットされて無視されます。

無視する値

送られてきた値を無視して、フィールドに静的な値を持たせたい場合は以下のようにします。

case class User(id: Long, name: String, email: Option[String])

val userForm = Form(
  mapping(
    "id" -> ignored(1234),
    "name" -> text,
    "email" -> optional(text)
  )(User.apply, User.unapply)
)

あなたは今、Optionな値、ネストされた値、同名の複数の値を混在させて、複雑なformを作成することが出来ます。


以上で終了です。

Play framework2.0のテンプレートエンジン部分意訳

Play framework2.0のThe template engineを意訳しました。

私は英語が苦手なタイプの人間なので間違っている部分は多々あると思います。
例のごとく、もし私の訳が間違っていても責任は負えませんのであしからず・・・
正確なものを読みたい方は原典をどうぞ。

http://www.playframework.org/documentation/2.0/ScalaTemplates

なお、日本Playframeworkユーザー会さんの方で翻訳作業が進行中のようですので、そちらを待たれるという手もあります。

それではどうぞ！

Play2.0のテンプレートエンジンはScalaがベースです

APS.NETのRazorにインスパイアされました。
コンパクトで簡単でどんなテキストエディタでも編集できます。
新しい言語を覚える必要はありません！

テンプレートはScalaだからコンパイルされます。
つまり、ブラウザで通常のプログラムと同じようにテンプレートのエラーを確認できます。

overview

Play2.0のテンプレートは、ちょっとしたScalaのコードを含んだシンプルなテキストファイルです。
HTMLやXML、CSVといった普通のテキストベースのフォーマットを生成できます。
テンプレートシステムは、デザイナが簡単に扱えるようにして、HTMLを快適に感じるようにしました。

テンプレートはコンパイルされて、普通のScalaの関数になります。
もし、「views/Application/index.scala.html」というテンプレートを作った場合、「views.html.Application.index」という関数が生成されます。

上記のディレクトリにファイルを作ったと仮定して、以下はシンプルなテンプレートの例です。

@(customer: Customer, orders: Seq[Order])
<h1>Welcome @customer.name!</h1>
<ul>
@orders.map { order =>
 
<li>@order.title</li>
}
</ul>

上記のテンプレートは、ただのテンプレートとしてだけではなく、どんなScalaコードからでも呼び出せます。
以下がサンプルです

val html = views.html.Application.index(customer, orders)

※注意（公式にない私的メモ）
Applicationというディレクトリがサンプルにあるけど、なんかこれはデフォルトコントローラのApplication.scalaと混同してしまって分かりにくかった。
viewsディレクトリの下に、「hoge/piyo.scala.html」というファイルを作った場合は、「views.html.hoge.piyo()」になります。
views.htmlは決め打ちで、後は通常のパッケージみたいに.区切りでディレクトリ階層を書いて行って、最後にテンプレートの先頭のファイル名（scala.htmlは不要）を書く感じ

@という魔法

Scalaテンプレートで、@を特殊な文字として扱います。
この@マークがある場所は、Scalaステートメントが始まる場所です。
@で始まるScalaステートメントをを態々閉じる必要はありません。
フレームワークがうまいことやってくれます。

Hello @customer.name!
       ^^^^^^^^^^^^^^^^^^^^^^^
        Scala code

テンプレートエンジンはあなたのコードを解析して、コードの終わりを自動的に検知してくれます。
ただし、もし複数のトークンを使うようなステートメントは明示的に括弧を使ってね。

Hello @(customer.firstName + customer.lastName)!
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                    Scala Code

さらに、普通のScalaコードのように中括弧を使ってステートメントを書くこともできます。

Hello @{val name = customer.firstName + customer.lastName; name}!
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                             Scala Code

そう！@は特殊な文字なのです。
時々@をエスケープしたいときもあるでしょう。
その時は@@を使ってください

My email is bob@@example.com

テンプレートパラメータ

テンプレートはシンプルな機能なので、引数が必要です。
テンプレートファイルの先頭行に宣言する必要があります。

@(customer: models.Customer, orders: Seq[models.Order])

さらにデフォルト引数も使えます。

@(title: String = "Home")

あと、いくつかのパラメータグループも使えます。

@(title:String)(body: => Html)

そしてimplictパラメータも使えます。

@(title: String)(body: => Html)(implicit request: play.api.mvc.Request)

イテレータ

Scalaのfor分は当然使えます。
ただし、以下の場合だとテンプレートコンパイラはコードブロックの上にyieldを置くことに注意してください。

<ul>
@for(p <- products) {
 
<li>@p.name ($@p.price)</li>

}
</ul>

恐らく分かるでしょうが、for分は典型的なmapのシンタックスシュガーになっています。

<ul>
@products.map { p =>
 
<li>@p.name ($@p.price)</li>

}
</ul>

ifブロック

ifブロックは特別なものではありません。
普通のScalaのifと同じように使い、以下のようになります。

@if(items.isEmpty) {
 
<h1>Nothing to display</h1>
} else {
 
<h1>@items.size items!</h1>
}

パターンマッチング

テンプレートの中でパターンマッチングを使うこともできます。

@connected match {
   
  case models.Admin(name) => {
    Connected as admin (@name)
  }

  case models.User(name) => {
    Connected as @name
  }
   
}

再利用可能なブロックの宣言

再利用可能なブロックを利用できます。

@display(product: models.Product) = {
  @product.name ($@product.price)
}

<ul>
@products.map { p =>
  @display(product = p)
}
</ul>

さらに、再利用可能なScalaによるコードブロックを宣言することもできます

@title(text: String) = @{
  text.split(' ').map(_.capitalize).mkString(" ")
}

<h1>@title("hello world")</h1>

Note：Scalaによるコードブロックをテンプレートの中で宣言するのは時々は有効な手段です。
しかし、複雑なロジックを記述するのに、テンプレートはベストな場所ではないということを覚えておいてください。
多くの場合、複雑なコードは純粋なScalaソースファイルに外出ししておいた方が良いです。
(views/パッケージの下にそういったソースファイルを格納することもできます。)

※注意（公式にない私的メモ）
つまり普通にテンプレートの中で関数を宣言できるということ。

PlayFramework2.0の決まりによって、再使用可能なコードはimplictという名前で定義されます。

@implicitFieldConstructor = @{ MyFieldConstructor() }

再利用可能な値の宣言

definingヘルパーを使って、スコープ内で再利用できる値を定義できます。

@defining(user.firstName + " " + user.lastName) { fullName =>
 

    Hello @fullName

}

ステートメントのインポート

テンプレートの先頭でインポートしたいものはどんなものでもインポートすることが来ます。
（もしくはサブテンプレート）

@(customer: models.Customer, orders: Seq[models.Order])

@import utils._

...

コメント

サーバサイドのみのコメントを@* *@を使って書くことが出来ます。

@*********************
 * This is a comment *
 *********************@  

テンプレートの最初の行にコメントを書くことで、Scala API docとして扱うことが出来ます

@*************************************
 * Home page.                        *
 *                                   *
 * @param msg The message to display *
 *************************************@
@(msg: String)

<h1>@msg</h1>

エスケープ

デフォルトでは、動的なコンテンツはテンプレートの種類に応じてエスケープされます。(HTMLとかXML)
もしエスケープさせずにそのまま出力したい場合には、出力したい生データをテンプレートのコンテントタイプでラップしてください。

  <p>@Html(article.content) <p> 

以上で、公式のテンプレートエンジン部分の意訳は終了！
PlayFramework1.2の頃に翻訳されたサイトを見ていましたが、チュートリアルが分かりやすいという点が本当に素晴らしいですね。
英語は苦手ですが、難しい表現もないようなので英語の勉強にももってこいなのでは？

PostgreSQLで複数レコードを一つのカラムにまとめる方法

PostgreSQLで、ARRAY関数を使って複数レコードを一つのカラムにまとめて取得する方法です。
この日本語だけだと、正直一体何を言っているの分からないので、実際の業務に絡めてみました。

まず、CDを管理するシステムを運用していると仮定します。
そして、各CDは必ずどこかのレーベルから発売されています。
さらに、各CDには複数のジャンルがあります。
各CDと各ジャンルを紐付けるために、それぞれのIDを格納したテーブルを使用します。

*******************************************************
各テーブルの情報
*******************************************************

・CDテーブル
 cd_id | label_id |     cd_name    
-------+----------+-----------------
     1 |        1 | I am Man part 1
     2 |        1 | I am Man part 2
     3 |        2 | hoge the CD

・レーベルテーブル
 label_id | label_name
----------+------------
        1 | label_A
        2 | label_B

・ジャンルテーブル
 genre_id | genre_name
----------+------------
        1 | Rock
        2 | Blues

・CDとジャンルを紐つけるテーブル
 genre_id | cd_id
----------+-------
        1 |     1
        1 |     2
        2 |     2
        2 |     3

ある日、営業にこんなことを言われました。

「全CDデータのCSV作ってよ。」
「カラムは、["CDのID", "CD名", "レーベル名", "ジャンル名"]でお願いね。」
「あ、各CDのジャンルは一行に纏めてね。とりあえず＆区切りとかでお願い。」

よくありますね。こういうの。
まぁこれくらいなら簡単に取得できそうです。
さっそく全データをSELECTだ！

*見やすいようにSQL文に改行を入れています

postgres=# SELECT c.cd_id, c.cd_name, l.label_name, g.genre_name
                  FROM cd c, label l, genre_reference gr, genre g
                  WHERE c.label_id = l.label_id
                          AND c.cd_id = gr.cd_id
                          AND gr.genre_id = g.genre_id;

 cd_id |     cd_name     | label_name | genre_name
-------+-----------------+------------+------------
     1 | I am Man part 1 | label_A    | Rock
     2 | I am Man part 2 | label_A    | Rock
     2 | I am Man part 2 | label_A    | Blues
     3 | hoge the CD     | label_B    | Blues
(4 rows)

ぱっと見て分かりますが、「I am Man part2」が2レコードありますね。
これはジャンルが2つ設定されているためです。
ということは、各CDを1行のCSV行にするためには、何らかの方法で各CDの情報をマージする必要があります。
ジャンルを省いた状態でプログラムでデータを取得して、再度全レコードに対してジャンル情報を問い合わせたり・・・
極端に難しい訳ではなさそうですが、面倒くさいですよね。
余計なSQLの発行にもなるし・・・

そこで、PostgreSQLのARRAY関数の出番です。
SQLを以下のようの書き換えて実行してみます。

*見やすいようにSQL文に改行を入れています

postgres=# SELECT c.cd_id, c.cd_name, l.label_name,
                          ARRAY (
                                  SELECT genre_name
                                  FROM genre g, genre_reference gr
                                  WHERE c.cd_id = gr.cd_id AND g.genre_id = gr.genre_id
                          ) as genre_name
                  FROM cd c, label l
                  WHERE c.label_id = l.label_id
                  ORDER BY cd_id;

 cd_id |     cd_name     | label_name |  genre_name
-------+-----------------+------------+--------------
     1 | I am Man part 1 | label_A    | {Rock}
     2 | I am Man part 2 | label_A    | {Rock,Blues}
     3 | hoge the CD     | label_B    | {Blues}

genre_nameが{}で囲まれて一つのレコードにまとめられました。
これがARRAY関数の機能です。
ジャンルに関連する部分を、SELECT内でARRAY関数を使ってサブクエリっぽくまとめてあげるだけで実現できます。
これで、各CD情報は完全に1行にまとめられました。
あとはプログラムで取得してCSVにするなり、vi等でゴニョゴニョするなり自由自在です。

ちなみにJavaだとjava.sql.Array型として取得できます。

java.sql.Array workCategories = this.resultSet.getArray("genre_name");
String[] categories = (String[]) workCategories.getArray();

参考

*******************************************************
DDL
*******************************************************

-- CDマスタ
CREATE TABLE cd( cd_id int, label_id int, cd_name varchar(64) );

-- レーベルマスタ
CREATE TABLE label( label_id int, label_name varchar(64) );

-- ジャンルマスタ
CREATE TABLE genre( genre_id int, genre_name varchar(64) );

-- CDとジャンルの関連を管理するテーブル
CREATE TABLE genre_reference ( genre_id int, cd_id int );


*******************************************************
テストデータ投入
*******************************************************
-- レーベルマスタのデータ
INSERT INTO label (label_id, label_name) VALUES(1, 'label_A');
INSERT INTO label (label_id, label_name) VALUES(2, 'label_B');

-- CDマスタのデータ
INSERT INTO cd (cd_id, label_id, cd_name) VALUES(1, 1, 'I am Man part 1');
INSERT INTO cd (cd_id, label_id, cd_name) VALUES(2, 1, 'I am Man part 2');
INSERT INTO cd (cd_id, label_id, cd_name) VALUES(3, 2, 'hoge the CD');

-- ジャンルのマスタ
INSERT INTO genre(genre_id, genre_name) VALUES(1, 'Rock');
INSERT INTO genre(genre_id, genre_name) VALUES(2, 'Blues');

-- CDとジャンルの紐付け
INSERT INTO genre_reference(genre_id, cd_id) VALUES(1,1);
INSERT INTO genre_reference(genre_id, cd_id) VALUES(1,2);
INSERT INTO genre_reference(genre_id, cd_id) VALUES(2,2);
INSERT INTO genre_reference(genre_id, cd_id) VALUES(2,3);
INSERT INTO genre_reference(genre_id, cd_id) VALUES(1,4);


*******************************************************
以下テーブル構成
*******************************************************
              Table "public.cd"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 cd_id    | integer               |
 label_id | integer               |
 cd_name  | character varying(64) |


              Table "public.label"
   Column   |         Type          | Modifiers
------------+-----------------------+-----------
 label_id   | integer               |
 label_name | character varying(64) |


              Table "public.genre"
   Column   |         Type          | Modifiers
------------+-----------------------+-----------
 genre_id   | integer               |
 genre_name | character varying(64) |


 Table "public.genre_reference"
  Column  |  Type   | Modifiers
----------+---------+-----------
 genre_id | integer |
 cd_id    | integer |