testem ってなに

testem

• testem via GitHub : airportyh/testem

Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests.

要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応しています。（デフォルトはJasmine）

test’em は“Test them”の省略形でしょう。 どんなテストもまとめて引き受けますよ！という事だと思います。

具体的になにしてくれるの

例えばJasmineで「基礎的で面倒なテストの開始の仕方」をした場合、

1. Jasmineのコードをとってきて設置し、
2. SpecRunner.html を編集し、
3. ブラウザでそのHTMLを開き、
4. テストを書いてブラウザをリフレッシュする

と、こんな感じの作業をプロジェクトの度に繰り返す事になります。

これが、testemでは

1. 設定ファイルを書く
2. testem コマンドを叩く

だけでテストが始まります。

インストール

もしnode.jsが既にインストールされている環境ならば、npmコマンドだけで簡単に導入できます。 （node.jsがまだ入っていないのであれば、まずそちらを先にインストールしましょう）

$ npm install -g testem

正常にインストールできませんでしたか？ 環境によってはsudoが必要になるかもしれません。

$ sudo npm install -g testem

これでtestemコマンドが使えるようになったはずです。 ヘルプでも覗いてみましょう。

$ testem -h

テストをしてみよう

早速テストをしてみようと思います。仮に、次のようなディレクトリ構造にしてみましょう。 scripts/.js がテスト対象のライブラリ、tests/.js がテストです。 testem.json が設定ファイルになります。

./
├ scripts/
│   └ foobar.js
├ tests/
│   └ test-foobar.js
└ testem.json （設定ファイル）

設定ファイルを書く

設定ファイルはJSONで記述します。必要最低限の設定は、こんな感じになります。

{
    "framework" : "jasmine",
    "src_files" : [
        "scripts/foobar.js",
        "tests/test-foobar.js"
    ]
}

• 
  

  framework
  
  使いたいテストフレームワークを書きます。デフォルトはJasmineなので、Jasmineを使う場合は省略できます。

  
  
• 
  

  src_files
  
  読み込むソースファイルを配列で記述しておきます。

  
  

テストを開始する

testemコマンドを叩けばテストは開始されます。

$ testem

実行すると次のような画面が表示されます。

表示されたURL（http://localhost:7357）を、テストしたいブラウザで開きます。すると…

ブラウザにはJasmineのテスト結果が。

ターミナルにもテスト結果が表示されます。

ファイル更新を検知してくれる

ソースファイルあるいはtestem.jsonを編集すると、更新を検知してブラウザとターミナルを自動的にリフレッシュしてくれます。 わざわざブラウザをアクティブにして更新する必要はありません。後はひたすらテストを書いていくのみです。

実行時に自動的にブラウザを開く

わざわざURLをコピーしてブラウザのアドレスバーに貼り付けるのが面倒！ そんな人の為に、“launch_in_dev”という設定項目があります。 設定ファイルにこれを追記する事で、testemコマンド実行時に自動的に、指定したブラウザでURLを開いてくれます。

{
    "launch_in_dev" : [
        "Chrome"
    ],
    ...
}

使えるブラウザのリストは、次のコマンドで知ることができます。

$ testem launchers

Windows環境ならIE7,IE8,IE9等も表示されますね。 公式のREADMEによれば、IE9のモード切り替えでのテストだそうです。

ただし、この設定はテスト開始時に新しいウィンドウを開いてしまいます。 その開き方が好きでない方は、大人しくブックマークに登録しておきましょう。 （私はそうしました）

Nettuts+ のチュートリアル

基本的な部分は上で紹介していますが、CofeeScriptのコンパイルを挟んだりなど、 もう少し突っ込んだ使い方はNettuts+のチュートリアル動画でわかりやすく解説されていました。 英語ですが、作業画面見ているだけでも参考になると思います。

Make JavaScript Testing Fun With Testem – YouTube

cf) Make JavaScript Testing Fun With Testem | Nettuts+

まとめ

面倒な部分を全部任せられるので、快適にテストをはじめられますね。 テストフレームワークだけでも有難いのに、至れり尽くせりで幸せです。

HybridAuthとは

HybridAuth, Open Source Social Sign On PHP Library

HybridAuth enable developers to easily build social applications to engage websites vistors and customers on a social level by implementing social signin, social sharing, users profiles, friends list, activities stream, status updates and more.

WebサイトにOAuth認証を簡単に設置する為のPHPライブラリです。 Twitter、Facebook等をはじめとした様々なサービスに対応しています。 サポートされているサービスは、現時点で32。

また、CodeIgniterやCake、Zend等のFWはもちろん、 WordPressやJoomula等のCMSのプラグインとしても利用できます。

• II. Third-party Plugins | Download HybridAuth

HybridAuth と Opauth の違い

HybridAuthはOpauthと似たタイプのライブラリですが、 この2者で大きく異る点、というよりはHybridAuthのメリットを2つご紹介します。

1. 自由にカスタマイズ可能なURL
2. APIにアクセスするメソッド

自由にカスタマイズ可能なURL

Opauthは、ログインURLの一部にサービス名を含んでいないと正常に動きません。 URLの文字列から認証するサービスを判別する為です。 （ここらへん、前回の記事では説明不足でしたね。すみません。）

例えば、「http://www.example.com/login/twitter」ならtwitterの認証画面へ、 「http://www.example.com/login/facebook」ならFacebookの認証画面へ飛ぶわけですね。

一方HybridAuthには、そういった縛りはありません。 そのかわり、認証メソッドの引数にサービス名を渡す事になります。

APIにアクセスするメソッド

Opauthは認証するだけでしたが、HybridAuthは認証した後にAPIにアクセスしてgetしたりpostしたりできます。 これ一本で全部面倒見切れそうですね。

簡単な使い方

HybridAuthを hybirdauth/ ディレクトリに保存したと想定して、 次のようなファイル構成にしてみます。

login.php (ユーザーがアクセスするページ)
config.php (設定ファイル)
hybridauth/ (ダウンロードしたHybridAuthの構成ファイル)
├ config.php
├ index.php
├ install.php
└ Hybrid/

設定ファイルを作る

hybridauth/config.php を参考にして、config.phpを作って必要事項を明記しましょう。 ここでは、Twitterのログインに必要な物だけを記載しておきます。

<?php

return array(
    "base_url" => "http://localhost:8080/hybridauth/",
    "providers" => array(
        "Twitter" => array(
            "enabled" => true,
            "keys" => array(
                "key" => "[your app's consumer key]",
                "secret" => "[your app's consumer secret]"
            )
        )
    )
);

base_url

実際にOAuthのやり取りをしてくれるスクリプトを指します。 多くの場合HybridAuthをインストールしたディレクトリになります。

providers

認証したいサービスの設定を列挙していきます。 Twitterの場合は、作成したアプリケーションのconsumer keyとconsumer secretを記載します。

ログイン処理を書く

./login.php を用意して、ログイン処理を書いてみます。

<?php

// 設定ファイルを引数にして初期化する（配列でもOK）
$auth = new Hybrid_Auth( "./config.php" );

// 認証の実行（未認証の場合はここでリダイレクトされ、認証済みの場合はスルーされます）
$twitter = $auth->authenticate("Twitter");

// ↓ ここから認証済みの場合の処理
echo "<h1>認証されています！</h1>";

// ユーザー情報をまとめてくれる getUserProfile() メソッド
var_dump(
    $twitter->getUserProfile()
);

// APIにアクセスしてみる
var_dump(
    $twitter->api()->get("account/verify_credentials.json")
);

コメントの通りです。authenticateメソッドだけでほとんど余計な処理は省かれて、スッキリしていますね。

実際の動作としては、こんな感じみたいです。

1. ユーザーがlogin.phpにアクセス
2. hybridauth/index.php に移動、そこからサービスの認証画面へリダイレクト
3. 認証が済んだらトークンをセッションに保存して、再びユーザーが元いたlogin.phpに移動

base_url について

config.php で出て来た base_url ですが、少し補足しておきます。

要するにこの項目は、全ての認証処理を代理で行なってくれるイケてるしヤバい hybridauth/index.php にアクセスさせる為の物です。 もっと言えば、そこにアクセスしたユーザーに対して hybridauth/index.php に記述されている処理が走りさえすれば良いです。

ですので、上の例示では hybridauth/ ディレクトリが公開ディレクトリにある前提になっていますが、 そうでない場合（非公開ディレクトリになっていたり、フレームワークの都合上アクセス出来なくなっていたりする場合）、 アクセスさせるファイル内で hybridauth/index.php をインクルードしさえすれば動くはずです。

例えば、”base_url” を /auth.php 等として、該当ファイルを設置し、

require_once("/the/path/to/hybridauth/index.php");

等としておけば良いですね。

気になった事柄

公式の例示では、APIアクセスも、認証済みである事を前提としていました。

認証を使わず、アプリに割り振られたのアクセストークンを使ったAPIアクセスは可能なのか、が気になりました。
それをするならそういうライブラリを使えば良いのですが、一つで済むならそれが一番ですよね。
気が向いたら調べてみます。

認証はOpauthで

• Opauth – Multi-provider authentication framework for PHP

Opauthは、様々なOAuth認証を一手に引き受けてくれる認証フレームワークです。

執筆時に公式に紹介されていた利用可能なサービスは、Twitter・Facebookなどを含め11件。 これらのサービスへの認証機能は「ストラテジー」という形で外部モジュールとして提供されます。 所謂ストラテジーパターンと呼ばれる物ですね。

その使い方は、認証のみにフォーカスしているライブラリなだけあって恐ろしくシンプルで簡単。 早速試してみます。

インストール

公式のダウンロードページからダウンロードするか、 Githubにリポジトリが公開されているのでそこからcloneします。

• ダウンロードページ
• GitHubリポジトリ

公式の「Opauth bundled with examples」からなら、Twitter、Google、Facebookのストラテジーも同梱されているので 最初に試す際にはこれがおすすめです。 （それ以外ではストラテジーが空っぽの状態なので、別途ダウンロードしてくる必要があります）

設定

ダウンロードして解凍・設置したら、設定ファイルを用意します。 opauth.config.php などとしておきましょう。

$opauth_config = array(
    /**
     * アプリケーションへのパス
     */
    "path" => "/the/path/to/",

    /**
     * Twitterで認証した後に戻るコールバックURL。
     * {path} は前述のpathを展開してくれる。
     */
    "callback_url" => "{path}callback.php",

    /**
     * ハッシュの生成に使われる文字列。任意の文字列を入れておく。
     */
    "security_salt" => md5("foobar"),

    /**
     * ここからがストラテジーの設定
     */
    "Strategy" => array(
        /**
          * Twitterストラテジーの設定
          * key, secret はTwitterの公式から取得。
          */
        "Twitter" => array(
            "key" => "[consumer_key]",
            "secret" => "[consumer_secret]"
        )
    )
);

consumer_key と consumer_secret は、 事前にTwitterでアプリケーションを登録して、自前の物を取得しておきましょう。

• Create an application | Twitter Developers

試してみる

Twitterの認証画面へリダイレクト

まず、Twitterの認証画面へリダイレクトするスクリプトを書きます。 ユーザはログイン時はこのページにアクセスする事になります。

<?php

require "/the/path/to/Opauth.php";
require "/the/path/to/opauth.config.php";

new Opauth($opauth_config);

ライブラリと設定を読み込んでインスタンスを初期化するだけです。
認証画面のURLの取得やらリクエストトークンの取得やらリダイレクト処理やら、
面倒な部分は全て代行してくれます。素晴らしい。

アクセストークンを取得

今度は、Twitterの認証画面から返ってきたユーザのアクセストークンを取得します。

デフォルトの設定では、認証情報は全て$_SESSIONに入るので
事前に*session_start()* しておきましょう。

<?php

session_start();

require "/the/path/to/Opauth.php";
require "/the/path/to/opauth.config.php";


/**
 * コールバック時には第二引数にfalseを入れて初期化する。
 */
$opauth = new Opauth($opauth_config, false);

/**
 * 認証情報を取得します。
 */
if(isset($_SESSION["opauth"]) && isset($_SESSION["credentials"])){

    $uid = $_SESSION["opauth"]["auth"]["id_str"]; // Twitterの数字のID
    $access_token = $_SESSION["credentials"]["token"]; // アクセストークン
    $access_token_secret = $_SESSION["credentials"]["secret"]; // 秘密のアクセストークン

}

コールバック時も、インスタンスを初期化してセッションから情報を取得するだけです。

ここで取得したアクセストークンを使ってTwitterAPIにアクセスするわけですが、
Opauthは認証を代行するライブラリなので、その為の機能は備えていません。
ここから先は、他のライブラリに代行してもらうことにします。

APIの利用はtmhOAuthで

• 
  themattharris/tmhOAuth
  

tmhOAuthは、PEARのServices_TwitterのようにTwitterAPIへのアクセスを代行してくれるライブラリです。
勿論認証機能も備えていますが、あまりにもOpauthが楽すぎたので作業分担をしてもらいます。

その特徴としては、（ほぼ）単ファイルで構成されていること。
tmhOAuth.phpをとってきて読み込むだけでその機能を利用する事ができるので、導入が容易いですね。
（正確には、tmhUtilities.php というユーティリティ用のファイルが同梱されていますが、
依存しているわけではありません）

試してみる

基本的には、前項で取得した4つのトークンを引数にして初期化して、
あとはTwitterAPIへのリクエストを行うだけです。

<?php

require "/the/path/to/tmhOAuth.php";

/**
 * tmhOAuthを初期化。
 * コンストラクタの引数はトークンをまとめた連想配列。
 */
$twitter = new tmhOAuth(
    array(
        "consumer_key" => "[consumer_key_for_your_application]",
        "consumer_secret" => "[consumer_secret_for_your_application]",
        "user_token" => "[access_token_of_the_user]",
        "user_secret" => "[access_token_secret_of_the_user]"
    )
);

/**
 * requestメソッドでTwitterAPIにリクエストを送る。
 * ここではユーザーのホームタイムラインを取得してみる。
 */
$status = $twitter->request(
    "GET", // リクエストメソッド
    $twitter->url("1/statuses/home_timeline"), // エンドポイントを指定
    array( "count" => 8 ) // パラメータ
);

/**
 * requestの返り値はHTTPのステータスコード
 */
if($status == 200){
    /**
     * データはメンバのresponseの中に、
     * さらに生のデータはその中の"response"の中にJSONで格納されている。
     */
    $response = $twitter->response;
    $data = json_decode($response["response"]);
    var_dump($data); // あとは煮たり焼いたりする
}

無事タイムラインを取得出来ましたでしょうか。
requestの返り値に注意しましょう。

こちらのライブラリもまた、かなりシンプルな使い勝手になっていますね。

まとめ

PEARのServices_Twitterには、個人的にいくつかの不安がありました。

• 
  ながらくβ版のままで、あまりメンテナンスされていない
  
• 
  ローカルコピーでプロジェクトに同梱しづらい
  

そこで他の選択肢を探していましたところ、
これらの2つのライブラリが候補として挙がって来ました。

お手軽さも上々なので、今後是非試していきたいリソースです。

はじめてのKohana

本連載は、私がKohanaに興味をもって導入し、色々試してみた記録をまとめたものなので、 あまり体系的に紹介できていない部分があるかもしれませんが、ご了承ください。 また、導入時に書いた物なので、そこまで突っ込んだ内容はありません。

続きを読む

インデックス

1. Hello World !

1. はじめに
2. Kohanaについて
3. インストール
4. 初期設定

2. コントローラとビューの基本

1. ルーティングとコントローラ
2. ビューを使って出力する

3. コントローラ

1. コントローラファイル
2. パラメータを受け取る
3. before / after

4. ルーティング

1. ルーティングを設定してURLをデザインする
2. パラメータを増やす
3. パラメータを省略する
4. 様々な形式のフィードを出力する

5. ビュー

1. ビューファイル
2. ビューに値を渡す（set）
3. 値を参照渡しする（bind）
4. 共用の値を設定する
5. ビューの中のビュー

6. モデルとデータベース

1. モデルファイル
2. データベースの初期設定
3. データベースインスタンスとクエリの実行
4. 結果を受け取る
5. クエリビルダー
6. プリペアドステートメント
7. DBクラスでのデータベース指定

7. バリデーション

1. 値のチェックができるValidクラス
2. Validationクラス
3. エラーメッセージのカスタマイズ
4. 独自のルールでチェックする

値のチェックができるValidクラス

単体の値のチェックには、Validクラスが使えます。

Valid::email("foo@example.com"); // <= TRUE
Valid::alpha_numeric("abcde12345"); // <= TRUE
Valid::url("http://www.example.com"); // <= TRUE

色々気の利いたバリデーション用メソッドが揃っているので、 詳しくは公式ドキュメントを確認してみてください。

cf) Valid | Kohana User Guide

Validationクラス

フォームで入力された値を一括してチェックしたり、エラーを管理したりする場合に使えるのが Validationクラスです。

初期化

まず、検査したい値を配列でまとめて、Validationに渡してインスタンスを生成します。 この配列は多くの場合$_POSTか、それを加工した物でしょう。

$vars = array(
     "name" => "john",
     "email" => "foo:example.com",
     "url" => "http:/www.example.com",
     "message" => ""
);

$validate = Validation::factory($vars);

ルールの追加

生成したインスタンスの rule メソッドを使ってルールを追加していきます。 今回のルールは以下のようにしてみました。

• name は8文字以上30文字以内
• email はEメールアドレスの形式で
• url はURLの形式で
• message は140文字以内で
• nameとmessageは必須

$validate
    ->rule("name", "not_empty")
    ->rule("name", "min_length", array(":value", 8))
    ->rule("name", "max_length", array(":value", 30))
    ->rule("email", "email")
    ->rule("url", "url")
    ->rule("message", "not_empty")
    ->rule("message", "max_length", array(":value", 140))
;

ruleの引数は、rule( $field, $callback, $params ) となっており、 $fieldにはフィールド名、$callbackには先に紹介したバリデーション用のメソッド名を、 そして$param には$callbackに渡すパラメータを設定します。

“:value” とあるのは入力された値を展開する為のプレースホルダです。

バリデートの実行

ルールを設定したら、check メソッドでチェックしてみましょう。 エラーがでなければ登録等の処理を行い、そうでなければエラーメッセージを表示する等します。

if($validate->check()){
     // バリデーションを無事通過したので、何か処理をする
     echo "Thanks !";
} else {
     // バリデーションエラーが発生
     echo Debug::vars($validate->errors("validation"));
}

errors メソッドの引数には、メッセージファイルの名前を渡します。 そして、返す値はフィールド名をキーにした連想配列になっています。

メッセージファイルの名前が “validation” の場合は、/application/message/validation.php か、無ければ /system/message/validation.php を参照します。 後者は雛形としてはじめから用意されているので、編集の際には書式などを参考にしましょう。

さて、先程渡した $vars はわざとエラーが出るような内容にしておいたので、 上のチェックの結果は次のようになります。何も弄っていなければ、フルイングリッシュですね。

array(4) (
    "name" => string(39) "name must be at least 8 characters long"
    "email" => string(29) "email must be a email address"
    "url" => string(17) "url must be a url"
    "message" => string(25) "message must not be empty"
)

エラーメッセージのカスタマイズ

デフォルトのエラーメッセージだと英語のアラートが出るなんだか怖いサイトになってしまうので、 日本語のメッセージに置き換えてみましょう。

メッセージを再定義

下記のファイルを編集、もし無ければ新たに作成します。

/application/message/validation.php

そして、今回使用するルールだけを以下のように再定義してみます。

return array(
     "not_empty" => ":field は必須項目です。",
     "min_length" => ":field は :param2 文字以上で入力してください。",
     "max_length" => ":field は :param2 文字以内で入力してください。",
     "email" => ":field はEメールアドレスを入力してください。",
     "url" => ":field はWebサイトアドレスを入力してください。"
);

:field はフィールド名、:param2 はメソッドに渡した第二引数を展開するプレースホルダです。 編集後に先程のエラーメッセージを改めて確認すると…

array(4) (
    "name" => string(53) "name は 8 文字以上で入力してください。"
    "email" => string(61) "email はEメールアドレスを入力してください。"
    "url" => string(61) "url はWebサイトアドレスを入力してください。"
    "message" => string(32) "message は必須項目です。"
)

メッセージが日本語化されました。が、フィールド名が英語のままで、気持ち悪いですね。

フィールドの別名（ラベル）を設定する

フィールド名には、別名（ラベル）を設定してそれを表示する事ができます。 ラベルの設定には label メソッドを使用します。

$validate
     ->label("name", "お名前")
     ->label("email", "E-Mail")
     ->label("url", "URL")
     ->label("message", "メッセージ")
;

このようにして改めて確認してみると、 以下のように無事、きちんとした日本語メッセージが表示されました。

array(4) (
    "name" => string(58) "お名前 は 8 文字以上で入力してください。"
    "email" => string(76) "E-Mail はEメールアドレスを入力してください。"
    "url" => string(61) "URL はWebサイトアドレスを入力してください。"
    "message" => string(40) "メッセージ は必須項目です。"
)

cf) Validation | Kohana User Guide

独自のルールでチェックする

rule メソッドの $callback に使えるのはValidクラスのメソッドだけでなく、定義済みの関数等も利用できます。

$validate->rule("user_id", "is_numeric"); // PHPの定義済み関数を使用
$validate->rule("user_id", "MyValid::is_user_id"); // 独自のバリデートクラスを使用

Validクラスのメソッドだけだと面倒、または冗長になるような場合、 独自のクラスを作ってみると見通しが良くなるかもしれません。

その場合は、メッセージも新たに追加してあげましょう。

return array(
    …
    "is_numeric" => ":field は数値で入力してください",
    "MyValid::is_user_id" => ":field の形式が正しくありません"
);

まとめ

全七回にわたってKohanaフレームワークの紹介をさせて頂きました。 Kohanaに興味を持った方へ、何かしらのとっかかりになれればなと思います。

» もくじ

1. Hello World !
2. コントローラとビューの基本
3. コントローラ
4. ルーティング
5. ビュー
6. モデルとデータベース
7. バリデーション

モデルファイル

Kohanaのモデルは次の場所に格納します。

/application/classes/model/

例えば、簡単なDataモデルを作って使用してみます。

/application/classes/model/data.php

<?php defined('SYSPATH') or die('No direct script access.');

class Model_Data extends Model {

         public function getItem(){
                    // なにか処理をする
                    return $item;
         }
}

コントローラでインスタンスを作って使用してみましょう。

$model = new Model_Data;
echo $model->getItem();

オートロードのおかげで、設置場所と命名規則さえ守っていれば簡単に使用する事ができますね。

モデル自体については特別これ以上書くことはなさそうなので、
続いてモデルと切っても切れないデータベースアクセスについて紹介します。

データベースの初期設定

Kohanaのデータベースの初期設定は、

/modules/database/config/database.php

にあります。が、これを直接編集はしません。
これを雛形にして下記のパスに独自の設定ファイルを作り、
あとはKohanaに設定をカスケーディングしてもらいます。

cf) Cascading Filesystem | Kohana User Guide

/application/config/database.php

ファイルの中身を見ると分かりますが、
Kohanaは複数のデータベースインスタンスを持ち、それを切り替えて使用する事が出来ます。
つまり、開発用・テスト用・本番用のデータベースアクセスの設定をスイッチング出来るようになっているのです。

詳細な設定内容については、雛形の内容をご参照ください。

cf) Configuration | Kohana User Guide

データベースインスタンスとクエリの実行

データベースインスタンスの取得は、Database::instance( $name ) を使います。
例えば、”development” という名前で設定しておいたデータベースのインスタンスは

$db = Database::instance("development");

このようにして取得する事ができます。
そしてインスタンスの query メソッドを使う事で、そのデータベースにクエリを送信します。

$result = $db->query(Database::SELECT, 'SELECT * FROM mytable');

queryの第一引数（Database::SELECT）は、クエリのタイプです。
SELECT/INSERT/UPDATE/DELETEがあり、それぞれ返す値が異なります。

• 
  SELECT : Database_MySQL_Result インスタンス
  
• 
  INSERT : insert id と列数を含んだarray
  
• 
  UPDATE/DELETE : affected rowsの数値
  

cf) Database | Kohana User Guide

結果を受け取る

Database::SELECTでクエリを送信した場合、結果が Database_MySQL_Result インスタンスで返されます。
この結果を1つずつ舐めて処理していきたい場合、例えば、次のようにします。

$result = $db->query(Database::SELECT, 'SELECT * FROM mytable');

foreach($result->as_array() as $row){
    echo Debug::vars($row);
}

as_array メソッドは、返された結果を連想配列で取得出来ます。

または、配列に変換せずに次のように処理する事もできます。これは上の例と同様の結果が出力されます。

while($result->valid()){ // valid は現在の行が存在するかを返す
    $row = $result->current(); // current は現在の行を返す
    echo Debug::vars($row);
    $result->next(); // next で次の行にポインタを進める
}

$result->rewind(); // rewind で最初の行にポインタを戻す

cf) Database_MySQL_Result | Kohana User Guide

クエリビルダー

データベースインスタンスを使ってクエリを送信する方法の他に、
DBクラスを利用した、より安全な方法が提供されています。
その一つがクエリビルダーです。

クエリビルダーは、メソッドを連ねていく事でクエリを動的に組み立てていくことができます。
CodeIgniterで言う所のActiveRecordのような物ですね。

// クエリの組立
$query = DB::select("id", "name", "created_at")
    ->from("users")
    ->where("id", ">", 3)
    ->where("name", "<>", "foo");

$query->execute(); // executeで実行

上のコードは、次のようなSQLを生成し、送信しています。
生成されるSQLは、$query->__toString(); で確認できます。

SELECT id, name, created_at FROM users WHERE id > 3 AND name <> ‘foo’

ここで挙げた以外にも組立に使える様々なメソッドが用意されています。

cf) Query Builder | Kohana User Guide

プリペアドステートメント

プリペアドステートメントも、クエリビルダー同様にDBクラスから提供されます。

$query = DB::query(Database::SELECT, 'SELECT * FROM `mytable` WHERE id = :id AND name = :name');

// parameters で値を渡す
$query->parameters(array(
    "id" => 123,
    "name" = "foo"
));

// param で1つずつ値を渡すこともできる
$query->param("id", 123);
$query->param("name", "foo");

$result->execute(); // executeで実行

bindによる参照渡し

また、param の代わりに bind を使用すると値渡しではなく参照渡しをする事ができます。
繰り返し同じクエリを処理する場合に便利ですね。

$query = DB::query(Database::SELECT, 'SELECT * FROM `users` WHERE name = :name');
$query->bind(":name", $name);

$names = array( "foo", "bar" );
foreach($names as $name){
    echo Debug::vars($query->__toString());
}

出力結果はこのように。

string(40) “SELECT * FROM users WHERE name = ‘foo’”
string(40) “SELECT * FROM users WHERE name = ‘bar’”

cf) Prepared Statements | Kohana User Guide

DBクラスでのデータベース指定

クエリビルダーやプリペアドステートメントでアクセスするデータベースを選択したい場合は、
executeの引数に設定名またはインスタンスを渡します。

$query->execute("development"); // 生成したクエリをdevelopmentに送信

// または

$db = Database::instance("development");
$query->execute($db);

または、Databaseの静的プロパティを書き換えても行けるようです。
セッターがないのでそういう使い方を想定しているかどうかはわかりません。

Database::$default = "development";

まとめ

Kohanaのモデルとデータベースについてご紹介しました。
次回は、本連載最後になります。Kohanaのバリデーションクラスについてのご紹介です。

» もくじ

1. 
   Hello World !
   
2. 
   コントローラとビューの基本
   
3. 
   コントローラ
   
4. 
   ルーティング
   
5. 
   ビュー
   
6. 
   モデルとデータベース
   
7. 
   バリデーション
   

ビューファイル

Kohanaのビューファイルはこちらに格納する決まりになっています。

/application/views/

例えば、単純に文字列を表示するだけの「hello」というコントローラー・ビューを作ってみるとします。

/application/views/hello.php

これがhelloビューの格納場所になります。 内容は適当に。

<!DOCTYPE HTML>
<html lang="ja">
<head>
     <meta charset="UTF-8">
     <title>Hello</title>
</head>
<body>

     Hello !!

</body>
</html>

では、このビューファイルをhelloコントローラーで出力してみます。

class Controller_Hello extends Controller {
    public function action_index(){
        $view = View::factory("hello"); // Viewクラスでインスタンスを生成
        $this->response->body($view); // 生成したインスタンスをResponseで出力
    }
}

View::factory( $name ) で名前に応じたビューファイルからインスタンスを作る事ができます。 ビューの出力は、基本的にこのインスタンスを使って制御する事になります。

この例では、”hello” という名前から /application/views/hello.php を元にしたビューのインスタンスを生成しています。

ビューに値を渡す（set）

実際の運用では、ビューファイルに値を渡して、それにより値を表示させたり切り替えたりすると思います。 ビューに値を渡すには、ビューインスタンスのsetメソッドを利用します。

$view = View::factory("hello");
$view->set("name", "John"); // set( $key, $value );

上記の形以外にも、連想配列で引数を渡したり、プロパティの追加でも値を設定する事ができます。

// 下の3つは全て同じ処理
$view->set("name", "John");
$view->set( aray("name" => "John") );
$view->name = "John";

setされた値は、ビューファイル側でキーの名前の変数にて参照できます。

Hello, <?php echo $name; ?> !!

値を参照渡しする（bind）

setは値渡しですが、bindメソッドを使えば参照渡しをする事も出来ます。

$foo = "bar";

$view = View::factory("hello");
$view->bind("foo", $foo);
$this->response->body($view);

$foo = "piyo";

（ビューファイルでの結果）

echo $foo; // <= "piyo"

setを使った場合は、上の出力結果は”bar”になります。

共用の値を設定する

複数のビュー・アクションで共通の値を利用したい場合は、set_global または bind_global を使用します。 beforeメソッド等で値を設定しておけば、そのコントローラー内の全てのアクションのビューでその値を参照できます。

set_global と bind_global の違いは set / bind と同様に、値渡しをするか、参照渡しをするかの違いです。

public function before(){
    View::set_global("title", "HELLO PAGE");
}
public function action_index(){
    $view = View::factory("hello");
    $this->response->body($view);
}

（ビューファイルでの結果）

echo $title; // <= "HELLO PAGE"

ビューの中のビュー

ウィジェット等の出力でよく使われると思いますが、 ビューの中にビューを展開する為の方法として、公式のドキュメントでは幾つかのアプローチが提案されています。 状況と目的に応じて使い分けるとよいでしょう。

ビューの中でインスタンスを生成する

基本的にそのインスタンスでset/bindした値しか使えません。

<?php
    echo View::factory("widget")->bind("foo", $foo);
?>

ビューの中でincludeする

より原始的な方法です。 特徴としては、親のビューのコンテキストで展開されるので、 親のビューで使用できる全ての値が子のビューでも使用できます。

<?php
    include Kohana::find_file("views", "widget");
?>

コントローラ内で、子のビューを親のビューにアサインする

親となるビューに、子のビューのインスタンスを生成して渡します。 コントローラで表示を操れるのが特徴です。

$view = View::factory("layout");
$view->widget = View::factory("widget")->set("foo", $foo);
$this->response->body($view);

cf) Views | Kohana User Guide

まとめ

Kohanaのビューについてご紹介しました。 次回は、アプリの核となるデータベースとモデルの話をします。

» もくじ

1. Hello World !
2. コントローラとビューの基本
3. コントローラ
4. ルーティング
5. ビュー
6. モデルとデータベース
7. バリデーション

ルーティングを設定してURLをデザインする

ルーティングの設定は、追加・編集する事ができます。

多くのケースはデフォルトのルーティングでまかなえるかもしれませんが、 ルーティングを駆使する事でよりユーザーフレンドリーなURLをつくり上げる事ができます。

幾つかのケースを例としてあげてみます。

パラメータを増やす

例えば、下記のようにパラメータにIDを渡して記事を表示するコントローラを作ったとします。

http://www.example.com/article/show/12345

これに対して、IDだけではなくカテゴリも渡したいとします。 カテゴリは、IDの前に挟む形とします。例えば、こんなふうに。

http://www.example.com/article/show/news/12345

これを実現するためのルーティング設定は、次のようになるでしょう。

Route::set(
    'article',  // 1. ルーティングの名前
    '(<controller>(/<action>(/<category>(/<id>))))', // 2. ルーティングルール
    array( 'controller' => 'article' ) // 3. ルールを適用する条件
);

名前は重複しなければ好きな名前で良いです。 第三引数の「ルールを適用する条件」は、URLがルーティングルールによって解析された結果、 “controller” の値が “article” である場合に適用する、という事を示しています。

“article” の部分は正規表現として処理されるので、 もしも “information” コントローラでもこのルーティングを使用したければ、下記のようにすればよいでしょう。

array( ‘controller’ => ‘(article|information)’ ),

パラメータを省略する

例えば、ユーザのプロフィールを表示するためのコントローラを作ったとします。

class Controller_Users extends Controller {
    …
    public function action_profile(){
        // プロフィールを表示する処理
    }
    ...
}

現状のアクセス方法は以下のようになっていますが、

http://www.example.com/users/profile/john

次のようにシンプルにしたい。

http://www.example.com/john

この方がよりわかりやすく、ドメインとユーザ名だけ覚えておけば簡単にアクセス出来ますね。 これを実現する為に、次のようなルーティング設定をしてみます。

/**
 * デフォルトのルーティング
 */
Route::set(
    "default",
    "(<controller>(/<action>(/<id>)))",
    array(
        "controller" => "(foo|bar|users)" // 定義済みコントローラ名を羅列
    )
)
->defaults(
    array(
        "controller" => "welcome",
        "action" => "index"
    )
);

/**
 * Controller_Users用のショートカット
 */
Route::set(
    "users_shortcut",
    "<user_id>(/<action>)",
    array(
        "user_id" => "[a-zA-Z0-9_]+" // user_id用の正規表現
    )
)
->defaults(
    array(
        "controller" => "users", // 初期設定のコントローラ
        "action" => "profile" // 初期設定のアクション
    )
);

前半部分は、元々あったデフォルトのルールを弄り、 既に定義済みのコントローラ名にマッチする物だけに適用されるようにしました。

後半は肝となるController_Usersのショートカット用のルールです。 ユーザーIDの書式にマッチする物であれば、Controller_Usersのアクションを実行するようになります。

(/) の部分は、ユーザーIDの後にメソッド名を渡す事で、 プロフィール閲覧以外のアクションが起こせるようにするための物です。

例えば、

http://www.example.com/john/favorites

等とすれば、Controller_Usrs の action_favorites が呼ばれ、 johnさんがお気に入りに登録した情報が表示される、といった事が出来ます。

尚、Kohanaでは controller と action はルーティングにおいて必須になっており、 上で挙げた例のように省略したい場合は、必ず defaults メソッドで初期値を設定してやる必要があります。

ユーザ名の予約語

ここで気をつけなければならないのは、このようなURLにする場合、 コントローラ名として定義されている物はユーザ名として提供できなくなるという事です。

それらを予約語としてリスト化する等して、登録時にはじく処理を加える必要がありますね。

様々な形式のフィードを出力する

ルーティングは、必ずしも /（スラッシュ）のみで区切られていなければならないわけではありません。 その一例として、RSSやAtom、JSON等、様々な形式で情報を出力したい場合のルーティングの例を挙げます。

Route::set(
    "feed",
    "<controller>.<filetype>",
    array(
        "controller" => "feed",
        "filetype" => "(xml|rss|atom|json)"
    )
)
->defaults(
    array(
        "action" => "index"
    )
);

コントローラはこのような感じで。

class Controller_Feed extends Controller {
    ...
    public function action_index(){
        $filetype = $this->request->param("filetype");
        // フィードを出力する処理
    }
}

次のようなパスでアクセスできます。

/feed.rss

cf) Routing | Kohana User Guide

まとめ

見通しの良いURLは、アプリケーションの使い勝手を向上させると思います。 URLのデザインにも気を使ってあげたいですね。

次回は、ビューについて。

» もくじ

1. Hello World !
2. コントローラとビューの基本
3. コントローラ
4. ルーティング
5. ビュー
6. モデルとデータベース
7. バリデーション

コントローラファイル

まずはコントローラファイルのおさらいから。

Kohanaのコントローラは、命名規則に従ってクラス名やアクション名をつけ、 application/class/controller に格納する決まりとなっています。

例えば、あるコンテンツに /foo/bar でアクセスしたい場合。

class Controller_Foo extends Controller {
    ...
    public function action_bar(){
        // do something
    }
    ...
}

こんな内容を、application/classes/controller/foo.php に保存すればOKです。

パラメータを受け取る

動的なWebページを生成する為には、URLを介してパラメータを受け取るのが基本です。

他のWebアプリケーションフレームワーク同様、 クラス名・アクション名の後にパラメータを渡して それをコントローラ内で受け取る事が出来ます。

例えば、「記事の詳細をIDを渡して表示させるアクションを作る」場合。

/article/show/12345

このようにして記事のIDを3つ目のパラメータとして渡します。 このIDをコントローラ側で受け取るには、 $this->request->param($key) とします。

class Controller_Article extends Controller {
    ...
    public function action_show(){
        $id = $this->request->param("id"); // <= "12345"
        // id を元にして何かをする
    }
    ...
}

上のコードではparamメソッドの引数には”id”なる文字列が渡されていますが、 これはルーティングの設定でそのようなキーが設定されているためです。

Route::set('default', '(<controller>(/<action>(/<id>)))')
    ->defaults(array(
        'controller' => 'welcome',
        'action'     => 'index',
    ));

ルーティングの設定は、bootstrap.php の最後に記載されています。 デフォルトでは下記コードのように、3つ目のパラメータが”id”とされている為、 paramメソッドで引っ張ってこれたわけです。

'(<controller>(/<action>(/<id>)))'

このルーティングは追加・編集する事で様々な事が実現できますが、 その話はまた別の機会に。

before / after

Kohanaのコントローラではコンスラクタは使用できません。（不可能ではないですが、推奨されません） その代替として、アクションメソッドの実行前後に処理されるbefore / after メソッドを使うことが出来ます。

before メソッド

アクションメソッドが実行される前に処理されます。

class Controller_Foo extends Controller {
    private $title = null;

    public function before(){
        $this->title = $this->request->controller() . " - " . $this->request->action();
    }

    public function action_index(){
        echo $this->title; // <= "foo - index"
    }
}

after メソッド

アクションメソッドが実行された後に処理されます。

下記はコントローラ名とアクション名から勝手にビューを出力してみる例。 fooコントローラのindexアクションの場合、ビューファイル “foo/index.php” を出力します。

class Controller_Foo extends Controller {
    ...
    public function after(){
        $name = $this->request->controller() . "/" . $this->request->action();
        $view = View::factory($name);
        $this->response->body($view);
    }
    ...
}

cf) Controllers | Kohana User Guide

まとめ

今回はKohanaのコントローラについて少し掘り下げました。 次回は、コントローラと切れない関係にあるルーティングの紹介をします。

» もくじ

1. Hello World !
2. コントローラとビューの基本
3. コントローラ
4. ルーティング
5. ビュー
6. モデルとデータベース
7. バリデーション

ルーティングとコントローラ

まず、前記事で表示された「hello, world !」の実体はどこにあるのか、から見てみましょう。 bootstrap.php を見てみると、末尾に次のような設定記述があります

Route::set('default', '(<controller>(/<action>(/<id>)))')
    ->defaults(array(
        'controller' => 'welcome',
        'action'     => 'index',
    ));

詳しい説明は省きますが、ここでは全てのパラメータを省略してアクセスされた場合のルーティングの設定をしています。 初期設定では、”welcome” コントローラの “index” アクションを呼ぶ設定となっています。 ではそのコントローラはどこに格納されているかというと、

/application/classes/controller/welcome.php

ここにあるわけです。コントローラは全て、このディレクトリに設置する決まりとなっています。 さらにファイルの中身を見てみます。

<?php defined('SYSPATH') or die('No direct script access.');

class Controller_Welcome extends Controller {
    public function action_index()
    {
        $this->response->body('hello, world!');
    }
} // End Welcome

中身を見ると、どのような命名規則になっているのか大体わかりますね。 このルールに則ってコントローラ・アクションを探し、無かった場合は404を返す仕組みです。

• ファイル名 : “welcome.php” （[name].php）
• コントローラ名 : “Controller_Welcome” （Controller_[Name]）
• アクション名 : “action_index” （action_[name]）

例えば /foo/bar でアクセスさせたい場合は、

/application/classes/controller/foo.php

を設置し、内容を次のようにします。

<?php defined('SYSPATH') or die('No direct script access.');

class Controller_Foo extends Controller {
    public function action_bar()
    {
        // do something
    }
}

ビューを使って出力する

上の例では文字列をそのまま出力していますが、Webアプリケーションを作る場合はビューファイルを使用します。
ビューファイルの格納場所は

/application/views/

です。ここでは名前を “foo” として、 foo.php を作ってみましょう。

/application/views/foo.php

中身は適当なHTMLを記述しておきます。
（実際は値を受け取る等しますが、それはまた別の記事で）

Hello !!

こんにちは！

次に、設置したビューファイルをコントローラから出力してみます。
先程作ったfooコントローラのbarアクションを編集しましょう。

public function action_bar()
{
    $view = View::factory("foo");
    $this->response->body($view);
}

View::factory(“[view_name]”); でビューファイルを基にしたビューインスタンスが生成され、
それを元に $this->response->body() で出力をします。

再度 /foo/bar にアクセスすると、設置したビューファイルの中身が出力されるはずです。

まとめ

Kohanaのコントローラとビューの基本的な点をまとめました。
次回は、コントローラについてもう少し詳しくご紹介します。

» もくじ

1. 
   Hello World !
   
2. 
   コントローラとビューの基本
   
3. 
   コントローラ
   
4. 
   ルーティング
   
5. 
   ビュー
   
6. 
   モデルとデータベース
   
7. 
   バリデーション