最初の考えは、標準型用のラッパークラスString、Integer、Float、Arrayの開発です。 これらのクラスは、入力データフィルターでの使用だけでなく、文字列、配列などのより便利な作業を目的としています。
例：
function test ( TFloat $a , TInteger $b ) {
}
//
test ( new TFloat( $_POST [ 'price' ]), new TInteger ( $_POST [ 'count' ]) );
コンストラクターのTFloat、TIntegerクラスは、いくつかの型変換操作を実行します。 たとえば、TFloatは、文字「、」を「。」に置き換えます。TFloatおよびTIntegerは、すべての非数字文字も削除します（TFloatはe +-を残します）。
しかし、いくつかの「ベース」クラスで管理することは困難です。異なる場合、同じTInteger型に追加の制限を課すことができるためです-たとえば、「最小（0）」、「範囲（2.10）」、「最大（5）」。 TStringの場合-「最小長（5）」、「regexp（/.../）」など
したがって、2番目の考えは、各基本タイプの追加のフィルター機能でした。
例：
TString:
- min #
- max #
- range # (min, max)
- match #
フィルタはtrue | falseを返す必要があります。これにより、検証ロジックを構築できます。 フィルタを使用して、独自のタイプを設計することもできます。
例：
Login :
TString :
#
# ""
- trim, toLowerCase
#
# ( !),
# ?
# error(some text) -
- ! match(/[a-z0-9_]/i) ? error( az, 0-9, _)
Password :
TString :
# /
- ! min(5) ? error( 5 )
- ! match(/[a-z0-9_]/i) ? error( az, 0-9, _)
Email :
TString :
- trim, toLowerCase
- ! match(/e-mail-regexp/) ? error(E-mail )
さらに、コードでは新しい型が使用されます（上記の構成に基づいてクラスが自動的に生成され、自動ロードメカニズムによってロードされる必要があります）。
<br/> function register( Login $login , Password $password , Password $confirm_password , Email $email ) {
<br/>}
ただし、この場合、追加のチェックが必要です。たとえば、$ passwordと$ confirm_passwordは同一でなければなりません。
したがって、関数自体については追加の説明がすでに必要です。
User : #
register : #
params : #
login :
type : Login
filters :
- empty ? error( )
# callback -
# , true|false
- ! callback(User->isLoginUnique($login)) ? error( , )
password :
type : Password
filters :
- empty ? error( )
# eq
# post.confirm_password - POST,
# get.confirm_password - GET - /path?confirm_password=123
- ! eq(post.confirm_password) ? error( "" " " )
confirm_password :
type : Password
filters :
- empty ? error( o)
すべての設定構文はYamlです。 また、フィルターなどを記述する方法が特に成功しているとは思いませんが、それほど重要ではありません。書かれていることについてのあなたの考えは興味深いものです。
建設的なコメントと批判を歓迎します...