タイトル/名前 | 更新者 | 更新日 |
---|---|---|
xmldom_whitspace_crossbrowser.zip | msakamoto-sf | 2009-10-04 17:20:29 |
JavaScript/select-optionタグによるメニューの動的更新 | msakamoto-sf | 2009-10-03 21:52:19 |
dynamic_dropdown_menulists.zip | msakamoto-sf | 2009-10-03 20:11:49 |
技術/TDD/JavaでUnitTestでprivateメンバにアクセスしたい場合 | msakamoto-sf | 2009-10-03 15:50:26 |
技術/TDD/JavaにおけるUnitTest時のMockオブジェクトの導入手法 | msakamoto-sf | 2009-10-03 13:33:10 |
JavaScript/select要素周りのメモ | msakamoto-sf | 2009-09-26 17:20:44 |
JavaScript/undefinedやnull値の"=="比較について参考リンク | msakamoto-sf | 2009-09-26 17:12:20 |
JavaScript/関数評価と括弧の微妙な注意点 | msakamoto-sf | 2009-09-26 17:03:37 |
JavaScript/オブジェクトリテラルのプロパティリストの末尾要素の","について | msakamoto-sf | 2009-09-26 15:51:01 |
日記/2009/09/24/TDDについて偉そうな事書いてしまったけど | msakamoto-sf | 2009-09-24 23:47:42 |
select-optionタグのメニューリストの各<option>タグの項目を、表示する瞬間にAjaxで動的に書き換える必要が仕事で発生した。
当初は"onMouseDown"イベントで書き換えようとしていたが、IEの場合にリストが上手く展開されない現象に悩まされた。
一時、<ul><li>タグでCSSを使ったドロップダウンリストで実装してみたが、今度はFlashが真下に来た場合のz-indexが効かない。
Flashの方でwmodeをtransparentにすることで回避できるが、代わりに、Flash中でテキストボックスがある時、IMEによる日本語入力が正常に表示出来ないバグがある事が判明し、wmode指定による手法は使えない事が分かった。
最終的に"onMouseOver"イベントで書き換える様にした。つまり、ユーザーがselectメニューの上にマウスを置いた時点で、<option>を書き換える。
書き換える際はAjaxによる通信で最新のリスト項目を取得する為、パフォーマンスに若干の不安があるが、アクセスがかなり限定される箇所だった事・取得元データ(MySQL)が元から非常に更新頻度が激しくフルスキャン前提のテーブル設計だった事などより、パフォーマンス的には意識する必要がないか、意識してもしょうがない状態だったため、そのままonMouseOverを採用する事にした。
作業現場では「あーでもない、こーでもない」と10個位試作品を作っていたが、今日、記憶を頼りにある程度家のPC上でゴールに至る道のりを再現したのでメモ代わりに書いておく。
HTML/JavaScriptなどは一通り次のzipファイルに収めてあるので、実際に動かしてみたい方はダウンロードして下さい。
dynamic_dropdown_menulists.zip
テストコードを書く時に困るのが、privateなメンバをテストしたい場面である。
そもそもprivateなメンバをテストコードでテストする必要があるのか、テストしたいのならprivateではなく別のクラスに移すべきではないのか、という意見はひとまずおいておく。
ここでは、下記記事で紹介されている、Javaでprivateなメンバを外部からreflectionを使ってアクセスする手法を例によって抜き書きしてまとめておく。
この記事はJUnitのFAQ "How do I test protected methods?" で触れられている。2003年後半の記事なので随分と昔であり、今更個人のBlogでメモ書きするまでも無いが、自分用のメモとしてまとめておく。
なお以下のJavaコードをコンパイル・実行したのは WinXP(SP2), JavaSDKは 1.6.0_12 を使っている。
最後の方にJUnitが出てくるが、こちらはEclipse3.2に入っていたjunit-4.1.jarを使った。
JavaでJUnitを使った単体テストのコードを書く時、Mockオブジェクトを使いたい、という場合がある。
例えばテスト対象のインスタンスメソッドの中で、トランザクションやデータベースの接続クラスのインスタンスをnewしていたりする時、
単体テストコードを作る為にMockのトランザクション/DB接続クラスに差し替えたい、というケース。
次のIBM developerworks の記事では、テスト対象のメソッドのインターフェイスを変えずに内部だけをリファクタリングし、
Mockオブジェクトに差し替える手法が紹介されている。
以下に、大まかなリファクタリングの流れやポイントを抜き書きする。
なおMockオブジェクトとは何か、テストコードを書く時どう便利か、などについては他の記事・書籍を参照の事。
(追記)
Mockオブジェクト作成の部分に限って言えば、Javaの場合は2009/10現在であればEasyMockやjMockライブラリがあるので、実際はそちらを使った方が良いかも知れない。
JavaScriptというよりはHTML寄りのメモになってしまうが、JavaScriptによる制御も混じりやすい内容なのでこちらにメモしておく。
select要素とは少しずれるが、<ul>や<li>とJavaScriptを組み合わせたDropDownメニューを使う場合がある。
この時、z-indexやpositionの指定によっては上手くDropDownメニューがオーバーラップしない場合があるらしい。そうした場合のトラブルシュートらしき記事が3件ほど見つかったので載せておく。
お仕事で試そうとしたのは、プルダウンメニューを開く時にAjaxでオプション項目を取得して生成し直す、という挙動。一応onMouseDownイベントに差し込む事で出来たのだけれど、onMouseDownイベント中でselectの要素をクリアしてAjaxの結果から追加し直す、とやってしまうと、現在選択中の項目が保持されず、項目が変わらなかった場合の挙動がおかしくなってしまう。
selectとoptions要素で実装するのは素直に諦めて、<div>やul/liなどの通常のDOM要素でプルダウンメニューを実装した方が良いかもしれない。
MSDNよりselect要素に関するMicrosoft公式ドキュメント:
undefinedの判定周りのWeb資料:
特に最後については、ECMAの仕様書まであたっているためもっとも精密と思われる。
自分もECMA262で確認済(*1)。
IE8/Firefox3/Chrome3で確認。
エラー:
function(){}();
正常:
(function(){})();
何となく書いてしまって正体不明のエラーに悩まされない為にメモ。
オブジェクトリテラルのプロパティリストの末尾要素の","というのは、
var o = { abc : 123, def : 456, ^ ここのこと };
である。
結論から言うと、ECMAの仕様上は末尾要素の","は定義されていない。つまり文法エラーとされても問題ない。
IE6/7/8の場合はエラーとなった。
一方Firefox3/3.5, Chrome3などではエラーにならなかった。
ECMA262, 11.1.5 Object Initialiserより:
ObjectLiteral : { } { PropertyNameAndValueList } PropertyNameAndValueList : PropertyName : AssignmentExpression PropertyNameAndValueList , PropertyName : AssignmentExpression
このように、末尾要素の","は定義されていない。
PHPやPythonなど近年のスクリプト言語の多くが配列やハッシュ形式の末尾の","を許してくれているので、JavaScriptでもついつい残したままにしてしまう。Firebugが便利なので、当初はFirefox上で作っていて、末尾","が残ったままIEで動作確認すると正体不明のエラーに遭遇した。ということでよくよく調べたらIE系は末尾","をまじめにエラーとしていただけの話。
いや、でも、マジで一昨日の私の3時間を返して欲しい。
数量的な根拠も何も無いので、単なる印象論と言われてしまえば返す口もない。
ふと思ったけど、TDDの所を「OOP」に読み替えれば、丁度Javaが流行出す前は同じような話があったのではないだろうか。要するに高い技術力とモチベーションを持った人間が継続して参画しないと、新しい技術は中々浸透しづらいという一般的な話になる。
じゃぁなんでOOPが浸透したかというと、これはOOPというよりはJavaやC++が浸透したので、必然的にOOPも浸透したと言っても良いのじゃないか。ライブラリがVisualC++のMFCであったり、VisualBasicのOOP実装であったり、WindowsのActiveXに浸透しているオブジェクト的な考え方であったりして、それを使って仕事をする為には半ばやむなくOOPを学習せざるを得なかったのではないか。
と言う事はTDDを言語レベルで強制するような言語で滅茶苦茶便利な言語がメジャーになり、キラーアプリなりキラーライブラリなどが整備されていけば、現場でもやむなくTDDを始める事になるのかも知れない。
例えばクラスやメソッドと対になるテストクラスやテストメソッドが存在しないとコンパイルエラーにする。
例えばテストコードによるコードカバレッジが90%以上でないとそのオブジェクトはリンクできない。(無理矢理リンクさせる事も出来るが、大量の警告ログが出力される、とか)
他にもtryにおいてUnreachableなcatchブロックは警告どころかエラーにするとか。
Objectは基本Immutable(変更不可)にするとか。
Noopとかそういう志向なのだろうか。