これまで４つのNamePickerを見てきました。
(1) codestore Jake Howlett(1)
(2) OpenNTF Jeff Crossett
(3) codestore Jake Howlett(2)
(4) OpenNTF Steve McDoagh
複数のノーツDBで、これらを使うことを想定して、この機能を文書ライブラリDBのレビューア（ReviewerList）に組み込んでみました。
目標動作は、次のとおりです。
・ノーツユーザ名の姓または名の最初の3文字を入力
・公開アドレス帳で該当ユーザを検索、
・ヒットした候補リストをブラウザ表示、
・候補リストから一人をクリックで選択、
・その人のフルネームをレビュー担当者フィールドにセット
ユーザの利便性、コードの保守性を考えると、おすすめは、「(2) OpenNTF Jeff Crossett」です。
文書ライブラリに移植しフルネームで候補リストを表示した画面を下に示します。
「(2) OpenNTF Jeff Crossett」は、プログラムコードが短く、分析・改造が相対的にもっとも容易で、コード(22K)のダウンロードにも時間がかかりません。
「(4) OpenNTF Steve McDoagh」は、機能的に優れていますが、yahooのライブラリが重くコード（190K）のダウンロードに時間がかかります。 ブラウザを起動して、NamePicker機能を使うアプリケーションフォームを最初に開くとき待たされます。 基盤環境変化時の対応も難しくなりそうです。ｄｏｍｉｎｏでは、dojoのライブラリ使用が今後増えていくと思われるのでｄｏｊｏとの競合が心配です。サーバエージェントの負荷も考慮しなければなりません。
「(3) codestore Jake Howlett(2)」は、コードがコンパクト(17K)ですが、難しい。なお、Domino6..Domino7用には、レスポンスを処理するプログラムの追加作成が必要です。
「(1) codestore Jake Howlett(1)」は、コードが78K。 コードはコンパクトですが、ボタンクリックで入力ウィンドウを開くことになり、利用ユーザは手間がひとつ多くなります。
移植は、次のパターンで実施しました。
1.コード管理用のノーツDBを用意し、そこにJavaScriptライブイラリ、CSSを配置
複数のNamepickerから共通して使用し、また、環境変化によって変更が必要となる可能性があるためです。
（イメージファイルは、変更可能性が小さいので利用DB側に配置）
例： (1)の場合
namepick15.nsf（例）に、lib/prototype.js、util/scriptaculous.js、css/NamePick.css、js/NamePicker.jsを配置
2.利用DB側のフォームのHTML HEAD CONTENTにライブラリ、CSSを指定してロード
例：(1)の場合
"<script language=\"JavaScript\" type=\"text/javascript\" src=\"/namepick15.nsf/lib/prototype.js\"></script>" + @NewLine +
"<script language=\"JavaScript\" type=\"text/javascript\" src=\"/namepick15.nsf/util/scriptaculous.js\"></script>" + @NewLine +
"<style type=\"text/css\" media=\"all\">@import \"/namepick15.nsf/css/NamePick.css\";</style>" + @NewLine +
"<script language=\"JavaScript\" type=\"text/javascript\" src=\"/namepick15.nsf/js/NamePicker.js\"></script>"
3.フォームのonLoadでinit プログラムが実行されるように指定
(JSライブラリのonLoadプログラムと競合して、これで動かない場合は、フォーム最下部に
パススルーHTMLで<script>エレメントで記述）
例：(1)の場合
サブフォーム化されていたNamePickerのdiv、NamePicker.init をフォーム最下部に記述
4.レビュー担当者フィールドのID名をプログラムから利用可能なものに設定または、initでフィールド名指定
例：(1)の場合
ReviewerListフィールドのIDに、ReviewerList を指定
ReviewerListフィールドの下に、候補リスト表示用の<div id="NamesList">を追加
＊利用側DBでのフォーム変更は、(1)が一番複雑で、他は、もっとシンプルです。
5.目標動作に合わせて、コードの一部を変更
リクエストを送るDB, ビュー名の変更
リクエストを送る条件を3文字以上に変更
利用しない項目がレスポンスで戻らないように、使用ビュー、(4)のサーバーエージェントを変更
readViewEntriesの結果の第二列を候補リストに表示するように変更
コード変更は、ロジカルな問題として対応可能ですが、環境により現れ方が異なる次の問題はやっかいです。
が、多数のDBでNamePickerを使うとなると、すぐに、あるいは、将来的に問題化する可能性があります。
(1) onLoad が動かない ＝ JavaScriptライブラリ問題
今回、利用側ＤＢにした文書ライブラリでは、名前入力フィールドの下方にリッチテキストフィールドがあります。
これが原因で、まず、onLoadのプログラムが動かない問題が発生しました。
HTMLのソースを見ると、プログラムした覚えのないdojoのスクリプトライブラリがロードされ、dojo.addOnLoadが動き、プログラムしたbodyのonLoadが動いていない。
（Domino8.5.では、リッチテキストフィールドがあると、自動的にJavaScriptライブラリのdojo、dojoのリッチテキスト入力モジュールがロードされます（ただし、Vista, IEでは、OS提供のモジュールが優先使用））
HTMLの解析後に動くdojo.addOnLoadは、HTML <body>のonLoadを無効化する。
dojo以外のJavaScriptライブラリにも、HTMLの解析後に動くプログラムがありえて、それが複数種のライブラリ共存に問題をおこすことがありうるとのことです。
このため、onLoadプログラムは、フォーム下部での<script>エレメントに記述して回避しました。
(2) 候補リストがリッチテキストの裏に隠れる ＝ OSの制御するアプレットはHTML要素の上じ表示される
これを回避するには、OSにより制御されるiFrameを用いるiFrame Sim という技法があります。
動的に表示したい候補リストのdivと同じ位置、大きさをもつiFrameエレメントを作成し、候補リストdivのz-Indexを1000などにして、iFrameエレメントのz-Indexをそれより１小さくするというような手法です。
ブラウザ、OS、Javascriptコード、ノーツ設計リッチテキストフィールドのWEBアクセス時の表示設定の組み合わせによってこの問題が発生するしないが決まります。
Vista IE8 Domino8.5の場合、リッチテキストフィールドのWEBアクセス時の表示をJavaアプレットにしなければ、裏に隠れることなく表示されましたが、Vista FireFox3.0.15 では、裏に隠れます。
今回のNamePickerプログラムでは「(2) OpenNTF Jeff Crossett」が、iFrame Sim を組み込み済みです。FireFox3.0.15でも候補リストがリッチテキストの上に表示されます。 (1)(3)(4)は、利用環境によっては、iFrame Sim を追加で組み込む必要があります。
なお、同じURLリクエストを繰り返さないというキャッシュ機能面でも、(2) OpenNTF Jeff Crossettは問題ありません。
ユーザの利便性だけでなく、ネットワークに与える負荷から見ても、タイプアヘッドによるユーザ選択入力は優れているのではないでしょうか。