さあいこう！

http://coderepos.org/share/browser/events/phpframework/piece_framework/trunk

機能をすべて実装したものの、まだまだチューニングや見えざる敵（bug）との戦いが控えています。
俺たちの戦いはこれからだ！



r15761 号をもってコミットメントは終了です。
ご愛読ありがとうございました。

IE における Piece Framework のハマりボタン

ページの中に準備された１つのフォームから、例えばいくつかの別ページへ遷移したり、何らかの処理を実施するため複数ボタンを準備するようなケースがあるかと思いますが、

<button type="submit" name="{__eventNameKey}_next" value="次へ" />次へ</button>
<button type="submit" name="{__eventNameKey}_back" value="戻る" />戻る</button>

なんでもないこのコード、IE では正常に動作しません。

具体的には、「戻る」ボタンを押したにも関わらず、「次へ」ボタンを押したように振舞ってしまいます。これは、フォームへの Submit が実行されると、準備された２つのボタンともにリクエストパラメータとしてPOSTされてしまうためです。ボタンには Piece Framework を制御するためのイベント名が付与されていますが、２つのイベントリクエストが飛んできてしまうため、実行すべきイベントが正しく認識できなくなってしまうのです。

ボタンによるイベントの切り替えを Form への Submit で行う場合は、<button> タグではなく <input type="submit"> で対応するようにしましょう。

<input type="submit" name="{__eventNameKey}_next" value="次へ" />
<input type="submit" name="{__eventNameKey}_back" value="戻る" />

Piece_Right で複数カラムのエラーメッセージを１つにまとめる

上記のような入力フォームで氏名の姓・名ともに入力値の必須バリデーションを行う場合、それぞれのリクエスト毎に必須確認およびエラーメッセージを設定すると、片方のみ未入力というケースならばよいものの、

両方ともに未入力の場合だと、上のような感じに。
これを回避しようとすると、テンプレート側で「どっちもエラーならば片方のみ表示して～」というような分岐文を書いてしまうところです。

ここは、次のようなバリデーションを行うようにします。

- name: lastName
  filter: &Japanese
    - trim
    - JapaneseH2Z
- name: firstName
  filter: *Japanese
- name: name
  required:
    message: 未入力です
  pseudo:
    format: %s%s
    arg:
      - lastName
     - firstName

これで、lastName, firstName のどちらかが未入力だった場合 name カラムもブランクとなり、required ルールにヒットしエラーとなります。あとはテンプレートにて name カラムについてのエラー処理を行えば OK です。もちろん、lastName, firstName の値もそのまま利用できます。

Piece_Right による複数項目を使った WithMethod 実行と finals

前のエントリでさらっと使用していたりするのですが、Piece_Right のバリデーションルールの1つである WithMethod において複数のリクエストカラムを使った処理を実施したい場合は、WithMethod で指定したメソッドの第3引数として渡される Piece_Right_Results オブジェクトを利用します。

function checkPassword($password, $context, $results)
{
    // username リクエストの値を取得
    $username = $results->getFieldValue('username');
    ....
}

なおここで受け取れる値は、既にバリデーション済みの対象に限ります。すなわち、このメソッドが実行される WithMethod バリデーションが行われる前に、あらかじめ username に対してのバリデーションが済んでいる必要があります。


バリデーションは、通常はバリデーションルールの書かれた yaml ファイル内の順に実行されますので username カラムを一番に記述しておけば問題はないはずです。確実に最終バリデーションとして実行したい場合は、validator とは別に記述することのできる finals を利用することで、すべてのバリデータ実行の後に改めてバリデーションを行うことができます。

- name: username
  required:
    message: ユーザ名を入力ください
  filter: &AlphaNumeric
    - trim
    - JapaneseAlphaNumeric
  validator:
    - name: Length
      rule:
        min: 6
        max: 255

- name: password
  required:
    message: パスワードを入力ください
  filter: *AlphaNumeric
  validator:
    - name: Length
      rule:
        min: 6
        max: 255
  finals:
    - name: WithMethod
      rule:
        class: AuthenticationAction
        method: checkPassword
      message: 認証に失敗しました

Piece Framework認証機構用コンポーネント Stable 版

ちょうど先週のことですが、Piece_Unity 向けの認証用コンポーネントの１つである Piece_Unity_Component_Authentication の Stable 版がついにリリースされました。

今年7月に Piece_Unity と付随するコンポーネント群が Stable 版として一斉にリリースされていた中、唯一このコンポーネントのみが Beta 版のまま残り続けていた状態でした。実はこの数ヶ月間の間に Stable 版として実用に耐えうるよう議論、実装、試用を続けてきたのでした。

リリースノートにも記載しているとおり、この Stable 版は過去バージョンの内容と一切の互換性はありません。したがって過去のバージョンからの移行は設定ポイントの修正が必要となりますので注意してください。

そしてもう１つ注意点として、次に紹介する Stable 版の機能を確認してしまうと、居ても立っても居られずに Stable 版の仕様に修正したくなってしまうかもしれません。:)


Piece_Unity_Component_Authentication は、以下の２つのポイントがあります。

• インターセプタープラグイン
• クライアント向けインターフェース

(1) インターセプタープラグイン

ベータ版当時より存在していたインターセプタープラグインですが、設定ポイントの内容が変更になっています。

具体的には、設定ポイントの階層が１つ上にあがっています。

以前は「services」設定ポイント以下に認証対象を指定する「resources」や認証フローへのアドレス「url」などを連想配列で指定していましたが、servicesを排除し「resources」「url」といった設定ポイントへ繰り上がることになりました。

また後述するクライアント向けインターフェースの登場により、認証確認のためのクラス・メソッドが必要でなくなりました。

認証機構が含まれるサイトを構築する際における、普段の認証向け設定ポイントのエントリは以下のようにすっきりしたものになります。

この例では、「/members/」というパスが含まれるURLにアクセスした場合に認証是非の判定が行われ、認証済み状態ならばそのまま実行、非認証状態ならば「https://<任意のドメイン>/login.php」へ自動転送される動作となります。

- name: Interceptor_Authentication
  point:
- name: resourcesMatch
  type: configuration
  value:
    - "/members/.*"
- name: url
  type: configuration
  value: https://example.com/login.php

(2) クライアント向けインターフェース

Piece_Unity 利用時における、認証に関する情報の保持・取得を行うためインターフェースとして、「Piece_Unity_Service_Authentication」という専用のクラスが新たに準備されました。

このクラスは、任意の Piece_Unity のフロー (例えば Authentication フロー) 内、つまりフローアクション内で利用します。

たとえばユーザに対して認証済みの状態にする場合、以下のように Service_Authentication の login() メソッドを実行します。

$authentication = &new Piece_Unity_Service_Authentication();
$authentication->login();

ログアウト時、すなわち非認証状態にする場合は、logout() メソッドを実行します。

$authentication = &new Piece_Unity_Service_Authentication();
$authentication->logout();

たったこれだけのコードで Interceptor_Authentication における認証是非の判定が得られます。


過去のバージョンを利用した認証機構サンプルコードでは、非認証状態時に元々アクセスしようとしていたURLへ認証後自動転送されるという処理コードを紹介していましたが、この機能も removeCallback() メソッド１つですべて実現できるようになりました。

恐らく認証後に転送されるという利用法になるでしょうから、以下のコードのように login() → removeCallback() と連続で実行するようにします。

$authentication = &new Piece_Unity_Service_Authentication();
$authentication->login();
$authentication->removeCallback();

(3) 認証フローサンプル

最後に、簡易的な認証フローを実現するためのサンプルを軽く紹介しておきます。これだけで認証状態のON/OFF切り替えと、元URLへの自動転送が実現できます。以前のものと比べて「かなり」スマートな内容になっているかと思います。（以前のものはもう書かない。）

* Authentication.yaml (フロー定義)

firstState: DisplayForm

viewState:
  - name: DisplayForm
    view: Form
    transition:
      - event: authenticate
        nextState: ProcessAuthentication

  - name: DisplayMenu
    view: Menu
    transition:
      - event: logout
        nextState: DisplayForm
        action:
          method: logout

actionState:
  - name: ProcessAuthentication
    activity:
      method: authenticate
    transition:
      - event: goDisplayForm
        nextState: DisplayForm
      - event: goDisplayMenu
        nextState: DisplayMenu

* AuthenticationAction.php (フローアクション)

<?php
require_once 'Piece/Unity/Service/FlowAction.php';
require_once 'Piece/Unity/Service/Authentication.php';
class AuthenticationAction extends Piece_Unity_Service_FlowAction
{
    function authenticate()
    {
        $this->_user = &new StdClass();
        $validation = &$this->_context->getValidation();
        if (!$validation->validate('Authentication', $this->_user)) {
            return 'goDisplayForm';
        }

        $authentication = &new Piece_Unity_Service_Authentication();
        $authentication->login();

        $authentication->redirectToCallbackURL();

        return 'goDisplayMenu';
    }

    function logout()
    {
        $authentication = &new Piece_Unity_Service_Authentication();
        $authentication->logout();
    }

    function checkPassword($password, $context, $results)
    {
        $username = $results->getFieldValue('username');
        if ( <$username, $password を使って認証是非を確認> ) {
            return true;
        } else {
            return false;
        }
    }
}

Authentication.yaml (バリデーションファイル)

- name: username
  required:
    message: ユーザ名を入力ください
  filter: &AlphaNumeric
    - trim
    - JapaneseAlphaNumeric

- name: password
  required:
    message: パスワードを入力ください
  filter: *AlphaNumeric
  validator:
    - name: WithMethod
      rule:
        class: AuthenticationAction
        method: checkPassword
      message: 認証に失敗しました

Piece Project 7月活動予定

今月関西圏で予定している Piece Project としての活動が2つあります。


まず 7/20(金) 京都にて開催されるオープンソースカンファレンス2007に Piece Project としてイベントに参加します。

オープンソースカンファレンス2007 Kansai Piece Framework講演のお知らせ

Piece Frameworkの概要について、セキュリティに関するお話を踏まえつつ解説する予定だそうです。14:00 からということですが、7/20のタイムテーブルを確認して他のイベントとあわせてどうぞ。


また 7/21(土) には、新大阪でオブジェクトリレーショナルマッピングを提供するプロダクト「Piece_ORM」の勉強会を開催。

第8回Piece Framework勉強会開催のお知らせ

実際にプログラムコードを書きつつ動作の確認を行っていきます。Piece_Unity サンプルアプリケーションとの電撃合体 (新日風) による実装例も。

Piece_ORM を動作させるために知っておきたい３つのディレクトリの役割

みんな大好き「○つの方法」的キャッチータイトルをパクるもこのエントリは流行らない･･･っ！


Piece_ORM を動作させるには、Piece_ORM クラスの configure メソッドを実行させることで動作環境を構築します。このメソッド実行には、３つのディレクトリを指定することになります。

実際にはPiece_ORM短期集中コースを読めば全て載っていることですが、この３つのディレクトリを簡単に理解するポイント、また使い始めてもふとやってしまう失敗ポイントをあわせてここでも紹介しておきます。


(1) configDirectory

設定ファイルを置いているディレクトリ。
一見とても重要な内容、というか事実そのとおりなのだが、実は指定するディレクトリに piece-orm-config.yaml という設定ファイルがあるかどうかというだけでしかありません。piece-orm-config.yaml は Piece_ORM を動作させるためのデータベース接続設定およびそれに付随するオプションを指定するためのファイルです。


(2) cacheDirectory

キャッシュデータが書き込まれるディレクトリ。
Piece_ORM はキャッシュデータ命というか、「キャッシュデータを作成」→「そのキャッシュを元に駆動する」という仕組みとなっています。「Piece_ORM が動作しない」というケースに出くわした場合、その原因は

・キャッシュディレクトリが存在しない
・プログラムがキャッシュディレクトリに書き込む権限がない

である可能性が高いでしょう。


(3) mapperConfigDirectory

データベーステーブルのマッパー定義ファイルが設置されているディレクトリ。マッパー定義ファイルはテーブルごとに存在します。
前述のキャッシュデータを作成するために、Piece_ORM で操作対象とするテーブルは全てファイルを準備する必要があります。「Piece_ORM が動作しない」理由は

・指定するテーブルのマッパー定義ファイルがない

という原因である可能性もあります。

この設定ファイルでは、任意のメソッドとそれに対応する任意の SQL クエリ、リレーションシップ定義を記述するようになっていますが、よく使われる汎用的なクエリメソッド (select, insert, update, delete) は定義することなく使用できます。
したがって簡単な動作を行う場合は設定ファイルを記述することはない、つまり 0 バイトのマッパー定義ファイルだけが存在することになります。

Piece Subversion でブランチ貰た

Piece_Unity と Piece_Right で専用のブランチを貰ったんですよ。何かあったらとりあえずここに commit すればよろしいと。
かなり特殊なことをしたりとか、規模が大きくなってきたりとかしたときに初めて分かることとかが、ある。実際ガリガリ使ってみてはじめて「こういう機能が欲しい」だったり「この値は使えるけどこの値を取得する方法がない」といったことが分かるので、まずはそういうところを主にやる予定。

Piece サンプル RPG 編

Piece FrameworkでRPG？（もどき） (Fool's Paradise)

その発想はなかったわ。



なかなか面白いサンプルで素晴らしいです。一見なんてことはない内容に見えるものの、「きちんと正しく、ズルできないように作る」としたら、Piece じゃなかったらかなり大変なはず。
フロー変数内にスタート時間などを突っ込んでおくと、終了時の時間との差分を算出してタイムアタック！なども出来ます。こちらも Piece じゃなければ、「ズルできないように作るとしたら」結構面倒。

ちなみにこのサンプル、世界が変転していて左右対称なファンタジーワールドですよ！

関西オープンソース2006に Piece Framework

関西オープンソース2006ユーザ企画Piece Framework講演のお知らせ

大阪南港ATC ITM棟で開催される関西オープンソース 2006 のユーザ企画の１つとして、Piece Frameworkの講演が行われます。
日時は 11/18(土) 11:00〜11:50。枠が50分しかない！ITEMAN ピンチ。

私も「認証機構」の部分について、現在すでに利用している内容を「いいだろ、いいだろー」と自慢話として何か話をするかもしれませんが、そのためにはサンプルを作らないといかんわけです。

第3回 Piece Framework 勉強会開催されます

第3回Piece Framework勉強会開催のお知らせ

いきなり第3回のような勢いですが。この度公にも告知してやろうということでの開催のようです。

ということで10月28日(土)、神戸にて行われます。私もリスナー兼サポートといういつも通りの立ち振る舞いで参加いたします。内容としてはサンプルアプリケーションを元に、この FW の内容と「色」をご紹介。

残り若干名ということで、参加を希望される方はお早めに。