Download the PHP package ryunosuke/chmonos without Composer

On this page you can find all versions of the php package ryunosuke/chmonos. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of ryunosuke/chmonos

Informations about the package chmonos

php/js Validation Library

Description

Install

Demo

Usage

基本

js チェックを行うのでいくつかの静的ファイルが必要です。 script ディレクトリ以下が該当します。

なお、 js チェックのエラー表示は完全に分離しているので比較的容易にすげ替えることが可能です。 上記の下2つのファイルがエラー表示を担当します。これらのファイルを変更することでエラー表示をカスタムできます。

php 側では下記に続くようなルールを配列で宣言的に記述して Form インスタンスを作成し、レンダリングすれば <form> タグが得られます。 その form で submit して validate メソッドで入力値の検証を行います（js バリデーションは原則として画面内で自動的に行われます）。

Form にはいくつかのオプションがあります。

上記が基本的な使い方となります。 example ではほぼすべての機能を使用しているので参考にしてください。

ルールの記述

Form のルールには下記のような連想配列を渡します。 大量にありますが、ほとんどはデフォルト値でそれなりに動くので、指定するのはごく一部です（究極的には空配列でも動きます）。

配列ではなく null を与えるとその要素はスルーされ、無かったことになります。

一部、難解なオプションがあるので掘り下げていきます。

normalize

バリデーションに先立って、値を引数にコールバックされるクロージャです。

php のみの設定です。js 側では使用されません。 基本的にはサーバーサイドでしか検知できない値のフィルタや変換を行いますが、そこまで用途はないでしょう。

condition

入力条件を指定します。

指定は原則として 条件クラス => [パラメータ] です。

とすると「入力必須」で「小数 xxx.yy」で「範囲 -200 ～ 200」を表します。

指定の仕方はいくつかあり、下記は全て正しい指定です。

基本的には 条件クラス => [パラメータ] で良いです。後からのハンドリングもしやすいです。 ただ、 「複数の同じ Condition を引数違いで使いたい（Compare など）」場合に対応できないため、そういう場合は他の指定方法を選ぶ必要があります。

各 Condition のパラメータはソースコードや DocComment を参照してください。 コンストラクタの引数がそのまま使用されます。

Child サフィックスがついている Condition は type=array 専用です。 このサフィックスがついている Condition は原則的に自身の行・列の列に対して串刺し的な条件を設定します。 例えば「行要素に特定の値を含む」「値の重複チェック」等です。

値が null でキーが数値だとスルーされ、無かったことになります。

message

エラーメッセージをカスタムします。

エラーメッセージは「form => input => condition => type => message」という階層構造を持ちます（フォームがインプットを持ち、インプットがコンディションを持ち、コンディションがエラー配列を持ちます）。 この構造の type => message 部分を指定します。

このようにするとエラーメッセージをカスタムできます。指定しないとデフォルトメッセージが使用されます（一応、それらしいメッセージにはなっています）。 上は直指定、下は定数指定ですが、変更に備えて定数指定を推奨します。

ただし、この指定だと「複数の同じ Condition を引数違いで使いたい（Compare など）」場合に全て同じメッセージになってしまいます。 個別でメッセージ変更したい場合はネストした配列を渡すことで condition => type => message の階層から指定することが出来ます。

condition1 や condition2 は condition 配列のキーと同じものを指定します。

また、メッセージ中に ${_name} という文字列を埋め込むとクラスの同名フィールドで置換されます。 例えば組み込みの Decimal Condition は '整数部分を${_int}桁、小数部分を${_dec}桁以下で入力してください' というものがあります。 この中の ${_int} ${_dec} はパラメータで指定した値に置き換えられます。

この記法は js のテンプレートリテラルを模しているため、${implode(",", _types)} のような式の埋め込みも可能です。 いくつかの Condition では使用しているため参考にしてください。 ただし、式として利用できる関数は内部で定義されているものだけです。 共通メッセージとして設定したものはビルド時に追加されますが、個別設定した場合は使用できません。 ので「共通で定義した上で個別で上書く」という処理が必要です。

なお、このキーでエラーメッセージを変更してもその要素のみに影響します。 js の容量削減のため、構造的には「共通メッセージがあり、変更した場合のみ個別メッセージが使われる」という動作になっています。 全体共通メッセージを変えたい場合は大本のクラスを書き換えるか AbstractCondition::setMessages を使用します。

エラーメッセージは一切 html エスケープが行われないので注意してください。 エスケープはエラー表示プラグインの仕事と割り切って、本体側ではタッチしない設計です。

options

checkbox, radio, select などの選択肢を指定します。 1階層のネストは optgroup として扱われます。

options が指定されると autocond 機能により InArray 条件が自動で付与されます。 invalids が指定されると autocond 機能により NotInArray 条件が自動で付与されます。その際、ラベル文字列はこちらの指定で上書きされます。

invalid-option-prefix を指定するとそのプレフィックスが付いた要素は invalids に入っているように振る舞います。 要素のプレフィックスは除去されます。

キーは値になります（1階層のネストは optgroup のタイトル）。 値はラベルになりますが、ラベルは stdClass が許容されます。 stdClass の場合、 label, invalid というプロパティが特別扱いされ、label がラベルに、invalid が上記で言う invalid-option-prefix が指定された値にあたります。 その他の属性は html の属性値になります。 つまり、下記のコードは（ほぼ）等価です。

違いは option に data-attr という属性値が生やせることです。

なんでこんな仕様が必要かと言うと、「現在選択肢が何らかの理由により無くなった」という仕様に耐えるためです。 例えばマスタから消えた、DB から論理削除された、等です（上記で言うと 30:FAX という選択肢が消えた状態）。

html の select は候補が不正な場合（value が 30:FAX なのに 30:FAX という option がない状態）に「一番上を自動選択する」という仕様があるので、何も考えずに実装すると画面を開いてただ保存しただけで値が 10:電話 に勝手に変わってしまう、という事象が発生します。 radio/checkbox はそういうことは起こりませんが、多くの場合は必須エラーとなりますし、現在の選択肢が何だったのか？ という情報が失われ、利便性が落ちます。 そのような時、invalids で無効候補を与えたり、prefix を付与することで現在の選択肢を保ちつつ NoInArray でエラーにすることができます。

選択肢が共通でマスタ的な場合は invalid-option-prefix がいいでしょう。定義場所で "\x18" を付与するだけで全体として無効化できます。 DB 等から動的に構築する場合は invalids がいいでしょう。options を取得するついでに invalids も取得すれば無効化できます。

event

js バリデーションが走るイベント名を指定します。基本的には change か input の2択でしょう。 特殊な仕様として jQuery の名前空間のように change.modifier とドット区切りで修飾子をつけるとそのイベントに対して特殊な属性をつけることができます。

noerror

event.noerror とすると「エラーになるときには発火しない」という動作になります。 逆に言うと「エラーが解除されるときのみ発火する」となります。

例えば ['change', 'input.noerror'] とすると「変更時にはエラーになるが入力時にはエラーにならない」という動作になります。 これは入力途中にエラーになると画面がうるさい or 邪魔になる、というよくある動作を回避するためのものです。

メールアドレスを入力しようとして hogera@ までタイプしてエラーになるのは確かにうるさいです。つまり input をつけることは出来ません。 一方、 [email protected] の入力ミスを修正するときは . を消した時点でエラーが消えるほうが親切でしょう。つまり input をつける必要があります。 そんなとき ['change', 'input.noerror'] とすると望ましい動作を実現することが出来ます。

norequire

event.norequire とすると「依存関係（propagate, dependent も参照）起因での検証のときに必須エラーを出さない」という動作になります。

例えば 希望連絡方法： ○電話 ○FAX ／ 電話番号[　　　　　　], FAX[　　　　　　] という UI で○電話にチェックを入れた瞬間に電話番号が必須エラーとなるのは時期尚早です。ユーザはまだ入力しておらず電話番号という項目があることすら認識していないためです。 かと言って propagate, dependent で依存関係を解除すると普通の検証イベントも伝播しなくなります。 この修飾子で抑制するのはあくまで必須エラー（Requires）だけです。

かなりニッチな用途でかつ破壊的変更の予定があります。 具体的には「DOM 順、座標が後方なら検証しない」という動作への変更予定があります。 作者が必要に迫られて新設された修飾子であり、一般向けではないので原則として使用は非推奨です。

propagate

要素に検証が走ったときに合わせて検証する要素を指定します。

例えば ☑ 必須： [　　　　　　] のような UI でチェックボックスにチェックを入れたときにテキストフィールドにイベントが伝播するように出来ます。 ただし、ルールからある程度推測して自動設定されるため、明示的に指定する状況はあまりありません。

これに関しては後述の dependent を参照してください。

phantom

他のフィールドの値を結合して自身の値とします。

例えば [年] [月] [日] の3フィールドがあるとして、自身の値は [年月日] として日付バリデーションをしたい場合です。

このようにすると年月日として構築されます。要するに vsprintf($phantom[0], ...array_slice($phantom, 1)) された値が自身の値になるということです。

inputs

ネスト要素を記述します。

このようにすると input 要素があたかも階層構造を持つような html が生成されます。 「画面内でボタンを押すと要素セットが追加される」ような状況で使用します。 ただし、かなり複雑になる上 context/template/vuefor の使用がほぼ必須になります。

なお、ネストできるのは2階層までです。それ以上ネストした場合の動作は未定義です。

ignore

最終的な結果から取り除くかを指定します。

Requires や Compare, phantrom などで「最終的な結果としては不要だが、ルールとしては必要」という要素が出てくることがあります。 例えば

のような状況です。 これらは依存関係の解決や、他の要素のためだけに存在しているもので、最終的な検証値としては不要なことが多いです。 そんなとき、 ignore: true を指定すれば最終的に validate や validateOrThrow で得られる値から自動的にフィルタされるようになります。

また、この属性には省略属性があり、@element_name のように要素名に @ を付与すれば自動で ignore: true とみなされるようになります。

needless

必須ではないときの html input 属性を指定します。

「必須ではない」とは「条件付き Requires が指定されているが、条件に一致していないとき」を意味します。 将来的に Requires と対を為す Condition が追加されるかもしれませんが、その意味合いは変わりません。

※ 「必須」なら必須だが「必須ではない」は入力不可を意味しない ※ 「入力不可」なら入力不可だが「入力不可でない」は必須を意味しない ※ つまり2値論理ではなく「必須」「任意」「入力不可」という3値論理なので Requires だけでは足りなくなっている

「必須じゃないときは入力できないようにする」「必須じゃないときは表示から消す」という要件が稀によくあり、そのようなときに js で頑張るのもつらいので組み込みとしています。

指定は任意の属性を指定できるようにしてありますが、実質的には下記の3属性のいずれかでしょう。 あるいは css での香りづけとして data- 属性を渡すことがある程度です。

どれも特徴があるので用途に合わせて選ぶべきです。 連想配列を想定していますが、上記のような論理属性であれば単一文字列・連番配列での指定も可能です。

なお、css の :has が十分実用的なので、

等のようにすればブロック単位で消すとか見えなくするとかの対応は js なしで可能です。 なので needless を指定しても属性付与に留め、DOM 構造には一切触らない実装になっています。

autocond

ルールの記述から condition が自動で設定できるようであれば設定します。 例えば

が自動設定されます。同種の condition が設定されているときは上書きしません。

この処理は Input クラスの _setAutoXXX を検出して自動で呼ばれるようになっています。 言い換えれば _setAutoHoge というメソッドを生やすことで condition の自動設定を拡張できます。

どの自動設定を行うかは配列で指定できます。例のように true/false で指定した場合は全設定/全未設定を意味します。

これは前述の「options があるときに InArray condition」だけを設定することを意味します。 また、 Input クラスに _setAutoHoge メソッドが存在するときに ['Hoge' => false] を指定すると Hoge も除外されるようになります。 指定されなかった condition は true 扱いになります。

true の代わりにクロージャを渡すと自動生成された Condition インスタンスを引数としてコールバックされます。 これは validationLevel や message を設定したい際に有用です。

dependent

依存項目を指定します。

propagate と対になる設定です。 propagate は「自身のイベントを伝播する要素（自身 -> 相手）」を指定しますが、この dependent は「自身へイベントを伝播する要素（相手 -> 自身）」を指定します。 あまり違いはありませんが、親から子、子から親の場合で指定の仕方が微妙に異なります。 また、 true にするとルールに基づいて自動で相手の propagate にマージされます。

例えば ☑ 必須： [　　　　　　] のような UI でチェックボックスにチェックを入れたときにテキストフィールドにイベントが伝播するように出来ます。 本来なら ☑ 必須 に対して propagate を設定するのが筋ですが、 [　　　　　　] に Requires(checked) のような条件が設定されていれば「チェックが入っていれば必須」という関連を自動で導き出すことが出来ます。 true はそれを設定するかしないかのフラグです。

true 単値でも ['elemname', true] のような配列でも指定できます。これは「elemname と自動設定」を意味します。

delimiter

配列⇔文字列の区切り文字を指定します。

区切り文字を指定すると自動で multiple も true になります。 そして値として文字列が飛んできた場合に区切り文字で自動で配列化されます。

主な用途は「URL の短縮」というニッチな機能です。 往々にして [] での配列のマルチ選択は URL が長くなりがちで、場合によってはブラウザの制限を超えることがあります（2000文字くらい）。

例えば multiple select などで something_id[] という名前で 100 件選択するとそれだけで something_id[]=10001&something_id[]=10002&...(約40文字) となり、全部で約 2000 文字になってしまいます（url エンコードや & 記号は除外）。 そのような時、このオプションで例えば , を指定すると something_id=10001,10002,...(13+6*100=613) となり、大幅に URL を短縮することができます。

変換は暗黙的に行われます。原則として利用側で意識する必要はありません。

multiple

値の複数値を許可します。 具体的には

デフォルトは null で、ある程度自動設定されます（デフォルト値が配列の場合など）。

pseudo

input のレンダリング時に直前に hidden を挿入します。

html における checkbox は未チェックだと値が飛ばないため、常にルールの default 値が使われてしまいます。 このオプションを設定すると未チェック時でも空文字・空配列（multiple 時）が飛ぶようになります。

さらに空文字が飛んだ場合の初期値としてこのキーに指定した値が使われます。 true を指定すると配列の場合は空配列、そうでなければ空文字を指定したのと同等になります。

原則として checkbox 専用ですが、multiple な select にも同様のことが言えるので multiple select も対象です。 その他の要素では単に無視されます。

default

値が飛んでこなかった時のデフォルト値を指定します。

明示的に指定するとそれが使用されます。 指定しないとルールに基づいて自動で算出されます。 例えば inputs が指定されていれば [] だし、 options が指定されていればその最初の値です。

この自動処理は互換性を保たず変更されるため、可能なら明示的に指定するようにしてください。

デフォルトでは「値が飛んでこなかった時」であることに注意してください。 isset でも strlen でもなく、本当になかったときのみに適用されます。端的に言えば array_key_exists 判定です。 ただし、それだとチェックボックスについては少々都合が悪いため pseudo でダミー hidden が生成できます。

nullable を true にすると値が null の場合でも default 値が使われるようになります。端的に言えば isset 判定です。

pseudo と default の違いは下記となります。

fixture

Form/Context には getFixture というメソッドが生えており、「その Form/Context の検証をパスするであろう値」を自動生成できます。 ただあくまで自動生成であるため、そのままでは検証を通らないことも多いです。

この fixture を指定すると自動生成ではなく、その指定した値が明示的に使用されるようになります。 クロージャを渡すとコールされます。これは「fixture なんてテストでしか使わないのに値を生成したくない」という状況を満たすためです。

その他のルール

ルールは上記のような既定キー以外でフィルタされたりはしません。 適当なキーで適当に値を渡せば $input->hoge で参照可能です。

これは拡張性を考慮してのことですが、将来の verup でキーが被ると互換性が崩れるため、何らかのプレフィックスをつけるなどで対処してください。

レンダリング

作成した $form オブジェクトを用いて下記のようにレンダリングします。

vuejs の機能を使うなら /* form の属性*/ に ['vuejs' => true] を与える必要があります。 これで v-model や :data-vinput-id などが出力され、 vuejs でもそれなりに動くようになります。

属性は基本的に name=value の連想配列を与えるだけです。 特殊な処理として「値が false の場合はその属性はなくなる」というものがあります。 これは readonly などの論理属性を想定しています。

form タグの属性はある程度よしなに設定されます。 例えば file 要素があると post な multipart/form-data になったりします。 しかし、レンダリング時に明示的に指定しているときは必ずそれが優先されます。

input タグの属性はいくつか特殊な属性があります（カッコ内はデフォルト属性）。

label タグの属性は特筆すべきことはありません。 敢えて言うなら for, class は自動設定されます（指定した場合はそれが優先）。

ファイル用のドロップ UI が用意されており、 .vfile-dropzone という DOM を準備しておけばそこにファイルがドロップできるようになっています。 ドロップされた時の file 対象は

です。つまり label ⇔ input の関係と同じです（W3C 違反だが気にしない）。 指定された file の files プロパティが更新され、 change イベントが発火されます。つまり、普通に選択した状況と全く同じになります。

file が見つかる/見つからないに関わらず .vfile-dropzone 自体に filedrop というイベントがディスパッチされます。 これは file を使用せずにプレビューを行いたい場合などで使えます。

バリデーション

上記でレンダリングした form タグで submit を行った先で下記のようにバリデーションします。

上記の通り、2通りの方法があります。

基本的には validateOrThrow を推奨します。 参照渡しはハンドリングしにくいし、検証エラーが起こった場合の処理は画一的であり、投げっぱなしの例外をフレームワークなどの共通処理部でハンドリングすればそれで事足りるからです。

なお、参照渡しだったり新しい値を返したりするのは本ライブラリは値の正規化も兼ねるという思想によるものです。 例えばルール外のキーを伏せる、 type=file をファイルパスにする、デフォルト値で埋める、など、「単に値を検証するだけ」では不便であり、その後「正しい値」が得られると便利です。 つまり、「検証するとともに完全に valid な値が得られる」がコンセプトとして存在します。

下記のようにすると condition によらない独自のエラーを追加できます。

いずれにせよ、エラーのハンドリングは必要ありません。 validate を通した後の form のレンダリングにエラー表示や値戻しが実装されているので、基本的に何もしなくても OK です。

明示的にエラーが得たい場合は getMessages getFlatMessages などのメソッドを使います。

context と template と vuefor

ルールの inputs 指定を行うとネスト構造が表現できます。 inputs を設定すると element[-1][subelement] のような name 属性で生成され、「ある特定のフィールドに紐づくフィールドセット」が定義できます。 これをレンダリングするには下記の context/template/vuefor メソッドを使用する必要があります。

なお、下記の記述では断りのない限り

というルールが記述されているものとします。

context

指定した連番に応じてフィールドセットを生成します。 開き/閉じは form と同様「引数ありで開き/引数なしで閉じ」です。

とすると

のようなタグが生成されます。 context メソッドの第2引数で連番を指定しますが、 null を指定すると __index という特別なキーが指定されたとしてレンダリングされます。

context メソッドは典型的には後述のように <template> タグの内部に配置します。 そのようにして得られた template タグを chmonos.birth に渡すと完全な DOM Node として得られるので、後はそれを追加したい箇所に appendChild すれば良いです。

もっと具体的な実際の使い方は下記のようになるでしょう。

レンダリング時に設定されている値分のフィールドセットを生成した上で、ボタンを click すると新しく DOM が生成されるようになります。 name や index, イベントなどは birth で設定されるため、上記がそのような動作を満たす最小のコードとなります。

template

上記の context メソッドはボイラープレートや重複コードが非常に多くなります。実際のデータレンダリングとテンプレートレンダリングが分離しているためです。 動的要素の使い方はある程度固定化されているため、それをある程度自動化したのが template メソッドです。

値分の foreach や template 部分がなくなり、非常にスッキリしました。 また、追加部分も単に spawn を呼ぶだけになっています。

それでも生成される html や動作は context メソッドを利用した場合とほぼ同じです。 実際のところ template メソッドは context でのボイラープレートを自動でまとめ上げただけに過ぎません。

あまり複雑なことは出来ませんが、単純に動的要素を追加したいだけなら template の方が便利です。

上記の通り data-vnode という属性を与えると値を用いてレンダリングされます。 vuejs のように双方向バインディングではありませんが、ちょっとしてテキストを埋め込む分には十分便利です。

data-vnode の値は将来的に動作を変えたりオプションを渡したりする想定です。現時点でいかなる値も与えてはいけません。

実装は js のテンプレートリテラルを動的に実行しています。 危険な文字列が来ると致命的なことになるので十分注意してください。

vuefor

基本的には context と同じです。 context で index を指定していた箇所に js の変数名を渡します。

上記で本ライブラリが使用する特殊な属性が : (v-bind) 付きで出力されます。 v-model も出力されるので vuejs における data を変更すれば適切な DOM が生成されるようになります。 v-model の修飾子を渡すには v-model.modifier 属性を指定します。

もっと具体的な実際の使い方は下記のようになるでしょう。

要するに「本ライブラリが動くに足る属性」を自動で吐き出すだけです。 context/template では初期化が自動で行われますが、 vuefor の場合は呼ばれないので mounted で明示的に呼ぶ必要があります。 この辺は example を参照するようにしてください。

ただし、あくまで補助的な機能です。vuejs をガッツリ使いたい場合には全く向いていません。 また、（必要に迫られての）実験的な機能でもあり、互換性保持の対象外です。この機能は破壊的変更が施される可能性があります。

どれを使うべきか

まず context と template と vuefor の挙動を一言で述べると

となります。 適しているシチュエーションとしては「動的追加がない（今あるデータだけでレンダリングしてポコポコ増えない）」場合は context、ある場合は template、vuejs を使用するなら vuefor が適しています。

エラーハンドリング

デフォルトでは condition の設定さえしておけば利用側では何もする必要はありません。

エラー表示をカスタムする場合は要素で validated を listen します。 これは検証が完了したタイミングでエラーオブジェクト（どのようなエラーが起こったのか）をイベント引数にして発火します。 基本的に本ライブラリは上記を発火するまでが仕事であり、どのように表示するか？ は管轄外というスタンスです。

なお、検証された要素は下記が設定されます。 これは上記のエラー表示とは無関係で常に行われます。

名前空間とディレクトリの登録

文字列指定で Condition を指定するときに、標準以外（組み込み以外）の Condition を使用する場合は名前空間とディレクトリの登録が必要です。 下記のようにすると任意の Condition を作成して組み込むことが出来ます。

名前空間とディレクトリは規定のものより優先されます。 つまり、既存同名 Condition の挙動を変えることも可能です。

また、 $outdir に phpjs というディレクトリがあるとその中にある js ファイルをマージします。 組み込みに無い関数や上書きしたい関数がある場合は phpjs に配置します。

独自検証の追加

上記の登録で文字列指定で Condition が使えるようになるので、そのディレクトリにその名前空間で AbstractCondition を継承した独自クラスを配置します。 基本的には組み込みのクラス（Uri あたりがシンプルで良い）を見れば書くべきことは分かると思いますが、いくつか作法があります。

getJavascriptCode メソッド

js での検証コードを返します。 返り値内に // @validationcode:inject というコメントを含めると下記の validate メソッドの中身がインジェクションされ、全体としての js コードになります。

つまり、 // @validationcode:inject を入れなければ完全に js コードのみとして動作します。 逆に // @validationcode:inject を入れることで変数の設定や事前処理などの「js だけの事前処理」が行えます。

もっとも、あまり使用機会はありません。事実、組み込みでもほとんど使っていません。 php/js であまりにも処理が異なる場合に使います。組み込みで言うと Unique が良い例でしょう（Unique は階層が絡むので共通コード化はほぼ不可能）。

prevalidate メソッド

validate メソッドに先立って行われる php だけの処理です。 上記の getJavascriptCode を使えば js の事前処理は行なえますが、php の事前処理は行なえません。 php で事前処理が行いたい場合に使用します。

こちらもあまり使用機会はなく、組み込みでもほとんど使っていません。 更にシンタックスさえ同じであれば下記の validate メソッドの中で $context['lang'] で分岐して記述することも可能です。 Unique で使用しているので参考にしてください。

validate メソッド

検証処理の本体を記述します。

各引数の詳細などはある程度後述しますが、原則として組み込みクラスを参照することで補完してください。 とりあえず重要な性質はこのメソッドのコードは js としても実行されるという点です。

php と js の言語としてのシンタックスはかなり似ているため、ちょっとした工夫を施せば割りとそのまま実行可能です。 そのちょっとした工夫をライブラリで吸収することでほぼ php コードで書くだけで js として実行できるようにしています。 具体的には書きませんが下記のようなものです。

validate には下記の引数が渡ってきます。

要するに php レイヤーでは self や $this で参照できるものが js では参照できないため、引数として渡ってくるものがほとんどです。 ただし $error だけはかなり特殊で、php 側ではメッセージキーかメッセージを渡すだけの動作ですが js ではそれに加えて下記の動作があります。

これは「php はメッセージが得られればそれでいい」のに対して「js は表示を行ったり非同期したりする必要がある」というレイヤーの違いによるものです。 とはいえ単純な condition であれば $error(文字列) しか使わないはずです。 この辺は組み込みの Ajax, ImageSize が参考になるかもしれません。

エラーの警告化

Condition の setValidationLevel を "warning" で呼ぶと、その Condition は警告化され、サーバーチェックがスルーされるようになります。 クライアントチェックは警告表示がなされ、エラーとは扱われません。そのまま POST することも可能です。

警告のハンドリングは下記の addCustomValidation で "warning" を追加します。

addCustomValidation

サーバーサイドでの検証が不要なら form.chmonos に addCustomValidation メソッドが生えているので、それを使用すると js による事前事後の検証が可能です。

それぞれ検証処理の事前・事後に登録した function がコールされます。 コールバック内の this は form 要素そのものを表します。

before/after はタイミングの違いであり、シグネチャなどに違いはありませんが、共通仕様として「false を返すとそこで中断される」というのがあります。 before で false を返すと、他の before イベントやその後の通常検証処理は実行されません。もちろん after も実行されません。 after で false を返すと、他の after イベントは実行されません。 いずれにせよ false を返すと検証結果としては false となります。

before は例えば特殊な UI の値化、完全なる前提条件の検証などに使用できます。 after は例えばファイル要素や非同期通信による一意チェックなどに使用できます。 warning は「エラーがなく、警告がある」ときのみ発火されます。ここで確認ダイアログなどを仕込めば「警告が出ているが POST を強行する」などが実現できます。

なお、js だけのチェックとなるので重要な検証には使用しないでください。例えば「どうせ外部キーが守ってくれるので画面で親切さを出したい」のようなあくまで利便性だけに留めるべきです。

Note

License

MIT

All versions of chmonos with dependencies

PHP Build Version
Package Version
Requires php Version >=7.4
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package ryunosuke/chmonos contains the following files

Loading the files please wait ....