pico-1.52になって、HTMLを書くだけ、というフォームメールシステムの仕様もほぼ確定したので、しばらくは実例でいきましょう。
繰り返しになりますが、基本構造はこれです。
<{capture}>
<form>
(フォーム記述部分)
</form>
<{/capture}>
<{formmail}>
<{capture}>
<form>
<input type="checkbox" name="好きなフルーツ" value="みかん" />みかん
<input type="checkbox" name="好きなフルーツ" value="りんご" />りんご
<input type="checkbox" name="好きなフルーツ" value="梨" />梨
<input type="submit" value="内容確認" />
</form>
<{/capture}>
<{formmail}>
<{capture}>
<form>
<fieldset>
<legend>好きなフルーツ</legend>
<input type="checkbox" name="favorite_fruits" id="favorite_fruits_orange" value="みかん" /><label for="favorite_fruits_orange">みかん</label>
<input type="checkbox" name="favorite_fruits" id="favorite_fruits_apple" value="りんご" /><label for="favorite_fruits_apple">りんご</label>
<input type="checkbox" name="favorite_fruits" id="favorite_fruits_pear" value="梨" /><label for="favorite_fruits_pear">梨</label>
</fieldset>
<input type="submit" value="内容確認" />
</form>
<{/capture}>
<{formmail}>
pico-1.51では、HTMLでValidateするルールが大きく変わりました。(ついでに、formmailプラグインそのものも大きく変貌しています)
(1)〜(3)も一部書き直しているので、古いのを読んでいた方はぜひ読み直してください。
今後、このHTML Validated Formシステムはいろいろな局面で流用すると思うので、デザイナーさんのためのルールを可能な限り詳しく記述します。
●項目名
name属性です。一通りのキャラクターが利用できます。日本語でも構いません。
配列も指定できますが、明示的に使う必要はほとんどありません。
●項目タイトル
<input><select><textarea>に対応する<label>がある場合、それを最優先に取得します。
checkboxやradioの場合は、<label>ではなく、所属する<fieldset>ブロック内の<legend>が最優先となります。
(<label>や<legend>ブロック内のテキストについているHTMLタグは除去されます)
<label>や<legend>が無い場合は、タグのtitle属性から項目タイトルを取得します。
上記のいずれからも項目タイトルが取得できなかった時には、項目名(name属性)が、項目タイトルとして扱われます。
●必須
class属性で指定します。
<input ... class="required" />
入力されていない、選択されていない時にエラーとなります
●型指定
class属性で指定します。以下のうち、いずれか一つだけが指定可能です。複数の型指定があった場合は、最初のものだけが利用されます。
- int
-- 整数型へ変換されます
- double
-- 浮動小数点型に変換されます
- singlebytes
-- 全角->半角変換の自動変換を行います
- email
-- 全角->半角変換の後、RFC2822によるチェックを行います。形式が合わなければエラーとなります。
- telephone
-- 全角->半角変換の後、電話番号を構成しなさそうなキャラクターが排除されます
第3回は、POSTデータを受け取るValidation(妥当性検査)をHTMLから判断する仕組みについて説明します。
(A)
Validationのもっとも基礎となる「受け取るべきフィールド名の一覧」は、簡単です。name属性から取ってくれば良いのです。
※もっとも、これも実はさほど簡単ではなくて、配列をどうするかとか、同じname属性のものが複数あったらどうするか、という問題はとりあえず先送りです。
(B)
次に、フィールドのタイトルです。フィールド名だけだといろいろ不便で、それと対応するタイトルもHTML記述だけで定義したいところです。(フィールド名がnameなら、タイトルは「名前」とか)
これについては、HTMLに<label>というちょうど良い仕掛けがあります。<input>に対応する<label>を書いてもらい、その<label>内のテキストをタイトルとするのです。そうすれば、HTMLとしても操作しやすくなるわけで、一石二鳥です。
(C)
3番目は、必須項目判定です。ただあいにく、HTMLに<input>が必須かどうかを示すような記法は、思い当たりません。これについてはかなり悩んだのですが(実は今も悩み中)、フィールド名で判断することにしました。フィールド名に、'_required' がついていれば、必須入力項目となります。
(1)のサンプルでは、「名前」のフィールド名が 'name_required' となっていました。これによって、名前が必須入力項目扱いされます。
1.51からは、genetさんのアイデアで、classを利用するようにしました。
(1)のサンプルでも、「名前」の<input>は、class="required" となっています。これによって、名前が必須入力項目となります。
(D)
最後は、型チェックです。ここでの型とは、int,double,string といった狭義の「型」ではなく、電話番号・email・住所なども含む広義の「型」です。これも悩んだ(でいる)のですが、とりあえずは、フィールド名によって自動判断することにします。
(1)のサンプルでは、emailというフィールド名がありましたが、このように、'email' という文字列を含んだフィールドは、電子メールとしての型チェック(RFC2822準拠)を行います。
(もし、このフィールド名が 'email_required' であれば、必須チェックも同時に有効になります)
1.51からは、やはりclassを利用します。(1)のサンプルで、「email」は、class="email"となっていますが、これによって、emailとしてのValidationを行います。(ドメイン存在チェックまではしませんが)
classですから当然複数指定可能です。emailを必須入力項目としたい場合は、class="email required" と指定すれば、emailとしてのValidationが行われて、かつ、必須項目として扱われます。
もちろん、この方法では限界があるので、最終的には、カスタムValidatorを簡単に導入できるようにするしかないでしょう。ただ、フォームメール程度であれば、必要な型チェックパターンも多くないので、一通り用意できると思います。
前回に示したサンプルフォームは、以下の様な構造で出来ています。
<{capture}>
<form>
(自由なフォーム要素記述)
</form>
<{/capture}>
<{formmail}>
いわゆるフォームメールは、デザイナーさんに完全にお任せしたいものの筆頭です。
でも、意外と嫌らしくて、結局プログラマーが手を入れる、なんてことになりがちです。
その最大の理由は、Validationでしょうか。
いろいろなフォームメールシステムを見てきましたが、どんなに簡単である、と謳っているものでも、フィールド定義が独自のXMLとかだったりします。そんな独自のXML仕様書を読まなければならないと考えただけで頭が痛くなる人も少なくないでしょう。
かといって、フォームを自動生成するタイプのフォームメール(XOOPSであればliaiseとか)は、デザイナーさんにとって使い物になりません。なぜなら、彼らはHTMLを自由に書くのが仕事だからです。
…というわけで、アイデアとしてはずっと温めていたHTMLによるValidationを試しに最新のpicoに実装してみました。
試しに pico-1.50 で、こんなコンテンツを作ってみてください(オプションはSmartyのみON)。もちろん、HTMLの部分は自由に記述できますが、checkboxおよびradioは、入力値を保存できません。(まだ作りかけ)
※ 1.51でcheckboxとradioにも対応しました
※※ 1.51で仕様変更があったので、サンプルコンテンツも変更しました。
もう少し細かな注意点は次回以降に書きます。