愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイッター
ヘルメットアタカ
F's Garage関連
このカテゴリ[Web系]の最新30件
モバツイッター、アクセス情報、iPhone対応、広告の話 えがちゃんが批判される理由は簡単、解決法も簡単 日記10/3:パソナテックイベント関連打ち合わせ Wire Free Gadgets Network 企業Webサイトには、そのあり様が現れる?! 動的URLのSEO効果について。 Webサービス事業者は、もっと広告をポジティブな関係にすべし。 はてブコメ一覧表示を一旦拒否して、また戻した ユーザーとしてのPerl,Ruby,PHP..... コミュニティの内輪性と寿命 ソニーイベント報告4日目/4:アプリキャスト ソニーイベント報告3日目/4:PetaMap モバツイ、セキュリティの取り組みについて。 ソニーイベント報告2日目/4:IPTVサービス branco ソニーイベント報告(1日目/4) :Life-X ネット系イベントが広げるべきスケーラビリティ そそそ、それ、カラメルでできるよっ! パソナテックイベントと、WebsigセマンティックWebイベント Joostがビジネス的にイケてないらしい。 Overtureのインタレストマッチの可能性 オープンソースと秘匿性のジレンマ CSSが普通に仕事で使えるようになった日 Google オープンソースのウェブブラウザ「Google Chrome」公開 カラメルのユーザー登録フォームの離脱率を調べてみた 何故、連載記事専用のRSSがないのか? 携帯向けツイッター(twitter)クライアントサービスのモバツイッター、携帯百景と連携 災害安否情報もモバツイをご利用ください、とか言っておくこと。 女性プロフィールがまとめる形で晒されてる件 何故、福山はvipperに人気があるのか。 月刊アスキー10月号斜め読み
[このカテゴリをもっと見る]
thatsPing
Powered by
Movable Type

March 25, 2007

■spryWidgetとはなんぞや?
spryWidgetを使うと、入力フォーム画面上のエラー処理がとても簡単になります。

使い方は、HTML上で、
<span id="spry○○">
<input type="text" name="any" id="any" value=""/><br />
<span class="textfieldMaxCharsMsg">128文字以内で入力してください。</span>
</span>

というHTMLを書いたとして、

<script>
var spry○○ = new Spry.Widget.ValidationTextField("○○", "none", {maxChars:128 , validateOn:["change"], isRequired:false});
</script>

などというスクリプトを書いてあげるだけで、スクリプトの引数に書いた条件で表示制御を勝手にやってくれます。

たとえば、maxChars:128と、validateOn["change"]というのが書いてありますが、この2つを指定すると、テキストフィールドに文字を入力中に128文字を超えると、自動的にエラーメッセージが画面に表示されます。また、文字数が128文字を下回ると自動的にエラーメッセージが消えます。

validateOn["change"]を外せば、submit時にこの処理が自動的に行われ、もしsubmit処理時にエラーがあったら、エラーメッセージを自動的に出力してくれます。特にonsubmitで何かを書く必要はなく、spryWidgetが勝手に制御してくれます。

isRequiredは、必須属性でデフォルトは必須になっています。何も書かないとsubmit時に値が入ってないと勝手にエラーを出してくれます。そのため、isRequiredをfalseにすることで、必須チェックをしないようにできます。

素敵です。

何より、textfieldのidやnameには一切触る必要がありません。一個、命名規則の決まったspanタグをフォームの前後に挿入し、エラーメッセージのクラスを設定したspanとエラーメッセージを置くだけです。

ダウンロードしてきたspryの中にあるwidgetsというフォルダの下にある、それぞれのフォームに適したJSとCSSをHTMLに張り付けるだけで上記機能が使えます。

<script src="/js/SpryValidationTextField.js" type="text/javascript" ></script>
<link href="/js/SpryValidationTextField.css" rel="stylesheet" type="text/css" />

ダウンロード先やデモについて詳しくは、adobeの上条さんのblog参照。
Spry (Ajax フレームワーク)公開

なお、本エントリの対象は2007/03/25時点に手に入るVersion1.4を対象としています。


■spryWidgetの作り上の問題点
1.spanにエラーメッセージってどうよ。
CSSをオフにするとエラーメッセージが丸見えなのでダサいという部分です。アクセシビリティもよろしくありません。

HTML上に何のエラーがあるのかも公表してしまっていますので、場合によってはセキュリティホールになるかもしれません。

なので、そこを割り切ってもOKと思われるときにしか使えません。

2.validationは自動化できるほど甘くない。
validation処理というのは、ユーザビリティに関わる複雑な処理なので、いろいろカスタマイズしたくなるります。

なので、いろいろエラー処理を追加したくなりますが、カスタムのエラーメッセージ処理もspryと同じ見た目の表示をしなくてはいけません。

そのために僕はspryのエラー処理を調べて、カスタムのエラー処理を付け加えられるようにしています。

spryのエラーメッセージ制御は、spryフレームワークのcssファイルを見てもらうとわかるのですが、要するに、

「.textfieldなんとかMsg」というメッセージの表示非表示を切り替えます。

この「なんとか」というのがエラー内容と対になっています。

しばらくよくわからなかったのが、「.textfieldなんとかState」 というHTML上にはどこにも出てこないクラスがCSSファイル上には存在していて、こいつが見た目制御に重要な役割を果たすようです。

CSSの構造的には「.textfieldなんとかState」の下に、「.textfieldなんとかMsg」のクラスがぶらさがっているみたいです。どうやらStateを切り替えることで、エラーメッセージ部分の表示非表示が切り替わるということです。

JavaScriptで、自分で制御するならこんな感じです。このクラスはSpryのオブジェクトの中に入っているstaticメソッド扱いですので、spry○○のオブジェクトなら何を使っても動きます。

エラーメッセージを表示する場合:
spry○○.addClassName($('spry○○'),'textfieldMaxValueState' );

エラーメッセージを削除する場合
spry○○.removeClassName($('spry○○'),'textfieldMaxValueState' );

第一引数は、エラーメッセージの枠を表すIDをgetElementByIdで取得するDOMオブジェクトです。
第二引数がエラーメッセージを表示するクラスです。なんとかMsgではなく、なんとかStateを引数に渡すのがポイントですね。

なので勝手にクラス名を追加してしまって、CSSファイルに該当するStateとMsgの記述を追加すれば自分で好きなエラーメッセージ機能を追加することができます。

3.onsubmitのタイミングを乗っ取られる。

spryは、何も書かなくてもonChangeやonsubmit時に処理をしてくれるのですが、自分のカスタムの入力チェックをしたいのに、onsubmitをspryに乗っ取られているのは気持ちのいいものではありません。

郷に入らずんば郷に従えということで、僕はspryのsubmit処理から、自分のクラスを呼び出すように機能を追加しています。

4.testAreaのValidationだけprototype.jsと衝突する。

prototype.jsにありがちな、よくあるforなんとかinの問題です。
JavaScriptのfor なんとか inは、データを蓄える連想配列じゃないから、こういうのに使うなというのが今のコンセンサスらしいです。

Spry.Widget.ValidationTextarea.prototype.switchClassName

というところにfor (var k in classes)と書いてあるところがを一か所だけあるので、for (var k = 0 ; k< classes.length ; k++)にするなり、prototype.jsを必須にしちゃうなら、eachを使って書くのもアリでしょう。

ということで、そうならないように書き換えればOKです(と簡単に言うな)

この辺はいずれかきますが、基本的にはバージョンアップ待ちかなとは思っています。
やっぱり改造してしまうとバージョンアップについていけなくなりますしね。なんかうまくフィードバックだけできればいいんですけど。


■ここから僕のメモ。忘れなければここに追加していきます。

基本的には日本とアメリカの違いに起因する不具合が多いです。

■■SpryVaildationTextarea
1.validateOn:["change"]をつけて、IMEを素早く入力するとIEが落ちる。firefoxは問題なし。

→残念ながら入力にあわせてのvalidationする処理はできません。TextFieldは問題なし。TextAreaだけの現象。

2.IME環境で文字数制限をつけたときに、文字数を超過した段階でIMEに入力すると、テキストエリアの文字が消える。
→ショボーンなので、該当処理をコメントアウト。文字数が超えたときのエラー表示を別途つけて対処。


■■SpryVaildationTextfield

1.メールアドレスのvaildationルールでは携帯アドレスでひっかかる恐れがある。
→これはよくある話。改造が必要。

2.URLのvalidation ルールも日本語URLとか通らないので。
→Spryがあるからってvaliadtionテストしなくていいよ、ではないので注意。

結構、組み込みのvalidationルールは微妙なのが多いです。
電話番号がどうのこうのとか郵便番号がどうのってのは、自分で付け加えた方が早いですね。

■同じカテゴリ[Web系]のエントリー
>>前の記事 はてブされるされないは、文章の書き方
<<次の記事 MacとWindowsのメリットデメリット
■このblogの書き込み最新3件
GoogleDan モバツイッター、アクセス情報、iPhone対応、広告の話 えがちゃんが批判される理由は簡単、解決法も簡単