PEAK XOOPS - News in englishin japanese

Archive | RSS |
  
Poster : GIJOE on 2007-09-15 06:01:46 (10521 reads)

in englishin japanese
pico-1.52になって、HTMLを書くだけ、というフォームメールシステムの仕様もほぼ確定したので、しばらくは実例でいきましょう。

繰り返しになりますが、基本構造はこれです。


<{capture}>
<form>
(フォーム記述部分)
</form>
<{/capture}>
<{formmail}>


今回は、最近対応したcheckboxをやってみましょう。

<{capture}>
<form>
<input type="checkbox" name="好きなフルーツ" value="みかん" />みかん
<input type="checkbox" name="好きなフルーツ" value="りんご" />りんご
<input type="checkbox" name="好きなフルーツ" value="梨" />梨
<input type="submit" value="内容確認" />
</form>
<{/capture}>
<{formmail}>

これが、一番簡単なパターンですね。
チェックすべきは、"好きなフルーツ[]" としなくても良い点です。
nameの最後に [] を追加しなければいけない、というのは、いかにもPHP側の都合なので、このシステムでは、そうしなくても、ちゃんと複数チェックを認識するようにしてます。

なお、このチェックボックスは、HTML的にはあまりよろしくありません。チェックボックスには<label>をつけるべきですし、<fieldset>でまとまっていないのもよくありません。name属性に日本語があるのを嫌がる人もいるでしょう。というわけで、同じフォームをこんな感じに書いてみます。

<{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}>

こういう構造でも、ちゃんと「好きなフルーツ」が項目のタイトルとなります。
checkboxとradioは特殊で、<label>から項目タイトルは取りません。
<fieldset>ブロックに所属している場合、直近の<legend>の中身を引っ張ってきます。
無ければ、title属性やname属性から引っ張ります。上の例では、name属性が、項目タイトルとなったわけです。name属性ですから、スペースなどを含むことは許されません。そういうキャラクターを利用したい場合は、<legend>で指定するべきです。


Poster : GIJOE on 2007-09-08 18:16:34 (9380 reads)

in englishin japanese
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
-- 全角->半角変換の後、電話番号を構成しなさそうなキャラクターが排除されます


Poster : GIJOE on 2007-09-06 06:31:17 (9750 reads)

in englishin japanese

第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を簡単に導入できるようにするしかないでしょう。ただ、フォームメール程度であれば、必要な型チェックパターンも多くないので、一通り用意できると思います。


Poster : GIJOE on 2007-09-05 05:45:07 (9882 reads)

in englishin japanese
前回に示したサンプルフォームは、以下の様な構造で出来ています。


<{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属性がそのまま項目名になります。

各フォーム要素の初期値も自由に記述してもらって構いません。一回投稿されれば、その部分は上書きされます。

以上、デザイナーさんのための簡単なドキュメントでした。
次回はプログラマーのために、動作原理についてもう少し踏み込んでみます。

0 comments

Poster : GIJOE on 2007-09-04 06:00:47 (15723 reads)

in englishin japanese
いわゆるフォームメールは、デザイナーさんに完全にお任せしたいものの筆頭です。
でも、意外と嫌らしくて、結局プログラマーが手を入れる、なんてことになりがちです。
その最大の理由は、Validationでしょうか。

いろいろなフォームメールシステムを見てきましたが、どんなに簡単である、と謳っているものでも、フィールド定義が独自のXMLとかだったりします。そんな独自のXML仕様書を読まなければならないと考えただけで頭が痛くなる人も少なくないでしょう。

かといって、フォームを自動生成するタイプのフォームメール(XOOPSであればliaiseとか)は、デザイナーさんにとって使い物になりません。なぜなら、彼らはHTMLを自由に書くのが仕事だからです。


…というわけで、アイデアとしてはずっと温めていたHTMLによるValidationを試しに最新のpicoに実装してみました。

試しに pico-1.50 で、こんなコンテンツを作ってみてください(オプションはSmartyのみON)。もちろん、HTMLの部分は自由に記述できますが、checkboxおよびradioは、入力値を保存できません。(まだ作りかけ)

※ 1.51でcheckboxとradioにも対応しました
※※ 1.51で仕様変更があったので、サンプルコンテンツも変更しました。

もう少し細かな注意点は次回以降に書きます。

Read more... | 1319 bytes more |9 comments

« 1 ... 4 5 6 (7) 8 9 10 ... 37 »
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!