PEAK XOOPS - News 
第3回は、POSTデータを受け取るValidation（妥当性検査）をHTMLから判断する仕組みについて説明します。
(A)
Validationのもっとも基礎となる「受け取るべきフィールド名の一覧」は、簡単です。name属性から取ってくれば良いのです。
※もっとも、これも実はさほど簡単ではなくて、配列をどうするかとか、同じname属性のものが複数あったらどうするか、という問題はとりあえず先送りです。
(B)
次に、フィールドのタイトルです。フィールド名だけだといろいろ不便で、それと対応するタイトルもHTML記述だけで定義したいところです。（フィールド名がnameなら、タイトルは「名前」とか）
これについては、HTMLに<label>というちょうど良い仕掛けがあります。<input>に対応する<label>を書いてもらい、その<label>内のテキストをタイトルとするのです。そうすれば、HTMLとしても操作しやすくなるわけで、一石二鳥です。
(C)
３番目は、必須項目判定です。ただあいにく、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}>
フォーム部分をSmartyプラグインのcaptureでくくって、その直後に、pico専用プラグインであるformmailを置く、という形になります。
「フォーム部分をキャプチャーして、formmailプラグインがその中身を解析し、POSTデータを受け取ってSESSIONに保存し、フォーム部分を書き換えて出力する」
こう書けば、動作も判りやすいでしょうか。
<form> には、actionもmethodもありませんが、実はこれ、特殊な形で、<form>となっている場合にのみ、actionとmethodを自動で書き換えます。
フォーム自身のURIがわかるのであれば、
<form action="/modules/pico/form.html" method="POST">
なとど明示的に記述しても構いません。この場合は、この部分の書き換えは発生しません。
フォーム要素記述部分には、自由にHTMLを書いてもらってかまいませんが、formmailプラグインが書き換える都合上、なるべく標準的な正しいHTMLを記述してください。
・タグ名などはすべて小文字で記述する
・<option>の選択済は、 selected="selected" とちゃんと記述する
・<input>などは、最後を必ず閉じる
・各フォーム要素（<input>等）については、なるべく、それに対応する<label>を記述する
formmailプラグインは、<label>を各フォーム要素の項目名だと判断します。
<label>がない場合は、フォーム要素のname属性がそのまま項目名になります。
各フォーム要素の初期値も自由に記述してもらって構いません。一回投稿されれば、その部分は上書きされます。
以上、デザイナーさんのための簡単なドキュメントでした。
次回はプログラマーのために、動作原理についてもう少し踏み込んでみます。
いわゆるフォームメールは、デザイナーさんに完全にお任せしたいものの筆頭です。
でも、意外と嫌らしくて、結局プログラマーが手を入れる、なんてことになりがちです。
その最大の理由は、Validationでしょうか。
いろいろなフォームメールシステムを見てきましたが、どんなに簡単である、と謳っているものでも、フィールド定義が独自のXMLとかだったりします。そんな独自のXML仕様書を読まなければならないと考えただけで頭が痛くなる人も少なくないでしょう。
かといって、フォームを自動生成するタイプのフォームメール（XOOPSであればliaiseとか）は、デザイナーさんにとって使い物になりません。なぜなら、彼らはHTMLを自由に書くのが仕事だからです。
…というわけで、アイデアとしてはずっと温めていたHTMLによるValidationを試しに最新のpicoに実装してみました。
試しに pico-1.50 で、こんなコンテンツを作ってみてください（オプションはSmartyのみON）。もちろん、HTMLの部分は自由に記述できますが、checkboxおよびradioは、入力値を保存できません。（まだ作りかけ）
※ 1.51でcheckboxとradioにも対応しました
※※ 1.51で仕様変更があったので、サンプルコンテンツも変更しました。
もう少し細かな注意点は次回以降に書きます。
mixiでminahitoさんやMarijuanaさんの日記を楽しく読んでいるのですが、頭が悪いとしか思えないコメントをつける人間がいて、どうにも不快で困ります。読み飛ばそうにも、無駄に長文だったりするので、肝心の流れが追えません。
どうしようかな、と悩んでいたら、tohokuaikiさんが素晴らしいエントリを教えてくれました。
mixi内のコミュニティのトピックで特定ユーザの発言を「display: none」にするGreasemonkeyユーザスクリプト
http://d.hatena.ne.jp/iwaim/20060906/1157520447
おお、なるほど。クライアントローカルなJavaScriptで不快なコメントを見えなくしちゃえばいいのか！
というわけで、このユーザスクリプトの日記版を作ってみました。
http://xoops.peak.ne.jp/uploads/ignore-user-for-mixi-diary.user.js
中身はほぼ一緒で、DOMにおける<tr>の相対パスが違うってだけです。
</tr>
<!-- 本文 -->
<tr>
となっていると、nextSibling が4つも必要だって事になかなか気づかずに苦労したのは秘密。「tableレイアウト(謎)としても腐ってると思った」という部分、同感です。
iwaimさんのブログやコメントはその切れ味の鋭さが大好きだったりしますが、その真骨頂がこれ。
http://d.hatena.ne.jp/iwaim/20060213/1139830786
このエントリを書いたiwaimさんが書いてくれたスクリプトのおかげで、エントリで批判している輩のコメントを目にしなくて済むようになった。
…不思議な縁を感じてしまいますね
ようやくというか今さらというか、d3pipesに更新Pingジョイントを追加しました。
あくまでジョイントですから、どのパイプのどの段階に挿入しても構いません。
SPAM Pingとして扱われないように、以下の２つのルールを適用してます。
- 前回から30分以内のPingは送信しない
- パイプ内を通っているデータが前回と違った時だけPingを送信する
当たり前ですが、そのパイプがゲストに公開されていないと、Pingに意味がありません。メインページだけでなく、RSSも許可することを忘れないでください。
それにしても、海外の有名どころなPingサーバはほとんどextended仕様なのに、国内はextendedってだけで拒否するサーバが多いんですね。extendedの方が、サーバ側の負荷も少ない気がしますが。