ペリフェラルの検査
XOOPS Cube 0.9 には XCube_ActionForm という検査クラスがある。 これを初めとして、Cube コアには XCube_ActionFilter など、自分自身意味が分かってないのに「名前合わせておけばOK」と思って採用した命名が結構ある。本当に今さらだがこの "Action" って何のことだったんだろう。*1
V1.0 では、無理に合わせることはやめて自分が想定している設計でいこうと思う。どのみちフレームワークやデータモデルにはコアは関与しないし、使っても使わなくてもいいクラスだから Web Developer には迷惑をかけなくて済む。 ActionForm のような紛らわしい名前を放置しておくほうが罪だろう。
ペリフェラルドライバ
世間的には今、データモデルに検査設定を書いて、入力値をそのままデータモデルに渡して、データモデル側で入力チェックを行うのが常識らしい。データモデルに不正な値を渡す可能性があるのは、入力だけとは限らないからだろうか。データモデルはプログラム内で比較的広くダイレクトアクセスされる想定なんだと思う。僕はどうしても、入力はシーンによって決まるのではなどと思ってしまうんですが……
XOOPS Cube のアクションフォームは、どこかに書いたけど、ペリフェラル制御がベースになっている。ゲームパッドの値が想定内に治まっていることを前提に続きのプログラムを書く。同時に入力値と検出値の割りふりもここでできるようになっている。
とはいえ ActionForm に合わせるために struts のコードも結構読んで合わせたし、そもそも exFrame からの引き継ぎの面が強いからどうしても中途半端になってしまう。 v1.0 ではこのへんを一新して、ペリフェラルなんちゃらに名前を変えるつもりだ。*2
ペリフェラルかネットコードベースか
ペリフェラルドライバにあたるのがリクエストクラス。そのへルパが検査クラスになるだろう。 XOOPS Cube の仮想サービス機能は、ダイレクトアクセスとネットアクセスを透過的に扱うが、「ペリフェラルに入力値を入れているのが誰か不明」の形で扱うか、「入力が相手クライアントで終わっていて、そのパケットが送られてくるイメージ」でいくかでやり方が変わってくる。
サービスの中でペリフェラル検査を走らせるイメージだと、APIの呼び出しに一度逆バインドが必要だが、この「ネットサービス前提で組んだコードをローカル通信に割り当てる」という考え方のほうが仮想サービス機能にピッタリくるかもしれない。