DOM で Table を操作するには？ [NT]
DOM （Document Object Model） で Table を操作したい。具体的には、ある条件に該当する行を削除したい。
Table に class が付属していれば xpath を用いて容易に Table を特定できる。
上記のコードでは Table に class_attribute という class 属性が付与されていると仮定している。 ここで得られた tbody は HTMLTableElement、rows は HTMLCollection である。
rows[0] とすれば、HTMLTableRowElement が得られる。これは最初の行を意味する。最初の行の最初の列を取得するには rows[0].cells[0] とする。これは HTMLTableCellElementである。rows[0].cells[0].textContent とすれば最初の行、列の文字列が得られる（そこに文字列があれば）。もし、最初の行、列の内容が画像やリンクだった場合は rows[0].cells[0].childNodes[0] のように子ノードを辿ればよい。こうして、最終的に行の内容を取得でき、その内容から削除すべき行か否かを判断する。
任意の行を削除するには tbody.deleteRow(i) とすれば良い。「i」は削除したい行の 0 から始まる行番号である。
もし、上記の処理をループで行う場合は、0 行目から順に行うのではなく、行の最後から行うと簡単にコードを記述できる。
Greasemonkey スクリプトの書き方 その3 [NT]
Greasemonkey スクリプトは Cookie のように永続的なデータを書き込んだり読み出したりすることが出来る。永続的に保存したデータは Cookie とは異なり勝手にサーバに送信されることは無い（永続的なデータを取得し、それをサーバに送信するような Greasemonkey スクリプトを記述すれば可能）。
永続的なデータの書き込みと読み込み方は次の通り。
保存できるデータは、文字列、ブール値、整数のいずれかで泣ければならないが、例えば配列であっても toSource() メソッドで文字列として保存し、読み込んでから eval すれば元に戻すことが出来る。同様なことはオブジェクトについても言える。Greasemonkey スクリプトの書き方 その2 [NT]
典型的な Greasemonkey スクリプトのひな形は次の通り。 Greasemonkey script execution environment や Greasemonkey script execution environment 2 によると、 最近は、Opera で動作させることを考慮しないのならば、必ずしも匿名関数を使う必要は無いようだ。とりあえず、ここでは慣習（バッドノウハウかもしれないが）に従った。
スクリプトによってはメニューを追加したいこともある。 メニューを追加するには GM registerMenuCommand を使う。典型的なコードは次の通り。
Greasemonkey には GM_registerMenuCommand を使うと、ページが読み込まれる度にメニューを追加してしまう不具合があったようだが、私の使用している Ver.0.8.20080609.0 では再現しない。修正されたのかな？Greasemonkey スクリプトの書き方 [NT]
Greasemonkey とは Mozila Firefox のアドオンである。Firefox が HTML を表示するときにユーザが記述したスクリプトを適用することができる。これにより、例えば、Google 検索結果で 10 件以上結果があるときに、いちいち次のページに移動しなくても、自動的に次のページを読みこむスクリプトを記述できる。
ちなみに、grease monkey という熟語には New College English-Japanese Dictionary, 6th edition (C) Kenkyusha Ltd. 1967,1994,1998 によると
【名】【C】 《俗》 （自動車・飛行機の）修理工, 整備士.
という意味がある。
Greasemonkey スクリプトの書き方については Dive Into Greasemonkey で公開されているマニュアルがとても詳しい。このマニュアルには日本語訳があり Dive into Greasemonkey[PDF] からダウンロード出来る。
Greasemonkey スクリプトは JavaScript を用いて記述する。JavaScript でコードを書くときは JavaScript Shell という便利なブックマークレットを使用すると良い。これを使うと、任意のページを開いて、そのページに対して JavaScript を書きその場で実行することができる。また、Tab による補完も可能なのでどのオブジェクトにどのメンバがあるのかとてもわかりやすい。
JavaScript に関する仕様書は Standard ECMA-262 からダウンロード出来る。この仕様書は Under Translation of ECMA-262 3rd Edition で日本語訳が公開されている。JavaScript で HTML を書き換える際には Document Object Model（DOM）の知識も必要になる。DOM とは HTML をツリー構造で表現したものである。DOM の仕様は Document Object Model (DOM) Specifications から入手できる。仕様書の翻訳は MetaGraphic Cell B4F - Scripts で公開されている。
Greasemonkey スクリプトの文字コードは UTF-8 が良いようだ。Shift_JIS などでは文字化けが発生する。
Managed Bean （Backing Bean） とは？ [IC]
NetBeans の Visual WEB ICEFaces はとても便利だが Java Server Faces の基礎を知っていないと悩むこともある。
例えば、既定では Page1.jsp と Page1.java というファイルが作成される。Page1.java は Managed Bean （Backing Bean と呼ばれることもある）に該当する。Page1.jsp にテキストフィールドを定義し、ブラウザからテキストを入力すると Page1.java にその内容が伝わる。Managed Bean は、このような裏方（サーバーサイドで処理をするような）の Java Beans である。
では、Managed Bean にメンバ変数を定義したとき、複数のブラウザからアクセスしたら、メンバ変数のデータはどうなるか。また、いつ作成・削除されるのか。
Managed Bean は faces-config.xml に作成したことを定義しなければならないが、このとき、managed-bean-scope 要素でインスタンスの生存期間を定義する。ここで設定した内容がポイント。例えば session にすれば、Managed Bean の生存期間は、あるユーザがセッションを開始して終了するまでになる。また、ユーザごとに（セッションごとに）インスタンスが生成されるため、複数ユーザ間の競合は発生しない。
本来は、HTTP はステートレスなので「どのユーザの処理を行っているか」を意識しなければならないが、Managed Bean を session で使用すれば意識する必要がなくなる。...らしい。
Servlet/JSP でのエラーページの表示 その5 [IC]
ここ最近、Servlet/JSP でのエラーページの表示について調査してきた（Servlet/JSP でのエラーページの表示 その4）。
最終的に不具合の状況が判明した。
- NetBeans の Visual WEB ICEFaces フレームワークを利用したときのみ web.xml に記述した error-page が無視される。
- 無視されるのは 500 （Internal Server Error のページ）である。
- 他は無視されない。
- Servlet コンテナは無関係。
- Icefaces 1.7.2 custom 500 error page + facelets に同様の投稿がある。
- NetBeans の ICEFace フレームワークを利用したときは問題が生じない。
ということで、ICEFaces と facelets を同時に利用したときの不具合。
これは気がつかなかったな。てっきり、web.xml など設定ファイルの問題か、Servlet コンテナ独自の設定の問題ではないかと思っていたので...
ICEFaces のフォーラムには既に投稿されているようなので次期バージョンでは修正されると良いなぁと思う。いったい、この問題に何時間費やしたんだろ。もったいない。
追記：VisualWeb ICEFacesの基礎の基礎 - しんさんの出張所 はてな編 という記事のコメントも参考になる。AJAX だとページ遷移するわけでは無いという部分が鍵だとは思うけど。
ホットデプロイとは？ [IC]
NetBeans のプラグインである j2ee.jetty を使用するとホットデプロイはサポートしていないと過去の記事に書いた。ところで、ホットデプロイとはどういう機能なのか。
ホットデプロイは製品によって表記が異なっている。ホット・デプロイ、ホット・デプロイメント、Hotdeploy、Hot deploy、Hot deploymentなど。
IBM の ヘルプ - WebSphere Application Server for OS/400, Version 6 では
サーバーの停止と再始動を行わなくとも、アプリケーションやそのモジュールにさまざまな変更を加えることができます。このような種類の変更のことを、「ホット・デプロイメントと動的再ロード」といいます。
としている。JBoss とは？ 【 Okapi Project 】 では
次に便利なのが、ホットデプロイでしょう。 これは、J2EE サーバ ( JBoss ) を停止することなく、プログラムの入れ替えが可能な機能です。
とある。＠IT：Java 製品紹介：JBoss 3 では
さらに、ホットデプロイ機能により、アプリケーションのデプロイも容易だ。JBossの起動後であっても、deployディレクトリにアーカイブ （EJB-JARやWAR、EAR）をコピー（もしくは展開してコピー）すれば、それらモジュールが読み込まれる。JBossを再起動する必要はない。こ れがホットデプロイと呼ばれる機能である。逆に、ファイルを削除すればアンデプロイとなる。ファイルを上書きすれば、アンデプロイ、デプロイが順番に実行 される。ホットデプロイは、アプリケーション開発時に重宝する機能だ。
と述べられている。[Think IT] 第4回：Javaのシステム更改を考慮していますか？ (2/3) では
「ホットデプロイ」という用語は、各製品共通の用語ではありません。今回の記事では、「アプリケーションサーバを停止せずに、アプリケーションを更新する方法」を「ホットデプロイ」と呼んでいます。
とある。私が意図したのは「アプリケーションサーバを停止せずに、アプリケーションを更新する方法」である。どれも意図は同じように読めるが、製品によって動作が異なるかもしれない。ホットデプロイという言葉の定義は存在せず、製品によりばらつきがあるようだ。
j2ee.jetty プラグインではホットデプロイはサポートしていないが、jetty 自体はサポートしているようだ。デバッグ時にこの機能がないと開発の効率が下がるので、j2ee.jetty プラグインにはまだ改良が必要のようだ。
Servlet/JSP でのエラーページの表示 その4 [IC]
NetBeans で Jetty プラグインを利用するには？その 2 の続き。
glassfish や tomcat では、JSP/Servlet で ServletException が発生したとき web.xml に記述した error.html が表示されるはずなのに表示されない。さて、jetty でも同様に発生するのだろうか？
web.xml に error-page を設定しないで ServletException を throw したのが次図。
error-page （500）を設定したのが次図。
問題なくカスタマイズしたエラーページが表示できている。
つまり、jetty では web.xml に記載した error-page が適用されている。尚、error-page は error.html を設定しており、このファイルはアプリケーションルート（コンテキストルート）上にある。
これまでの実験から、web.xml の記述そのものは問題無さそうである。glassfish と tomcat と jetty で web.xml の扱いが異なる？
問題がはっきりした。Servlet/JSP でのエラーページの表示 その5 に追記した。ICEFaces + facelets の不具合らしい。
NetBeans で Jetty プラグインを利用するには？その 2 [IC]
NetBeans の main/contrib をビルドするには？ その 4 の続き。
j2ee.jetty プラグインを NetBeans に組み込むと 「メニューバー」-「ツール」-「サーバー」で開くダイアログから Jetty を追加できるようになる。
これで NetBeans から Jetty が起動できるようになった。
このプラグインに対する設定項目はあまりなく、デフォルトのままで起動できる。ポートくらいしか変更できる部分はない。
次に、単純な JSP/Servlet を書いてプロジェクトの設定をしたのが次の図。
「サーバー」に「Jetty Web Server」が選択できるようになる。
実際に JSP/Servlet を実行してみると次図のように正常に実行できた。
少し試してみたところ jetty プラグインで幾つかわかったことがあるのでまとめておく。
- JSP/Servlet の実行は可能。
- JSP/Servlet のデバッグはサポートしていない（デバッグとして起動するとエラーメッセージが表示される）。
- JSP/Servlet を修正したら再配備が必要。このとき、Jetty は再起動が発生するため重い（数秒くらいか）。
civic site : Jettyでホットデプロイ という blog では Jetty でもホットデプロイが出来ると紹介されている。また、Debugging with the Maven Jetty Plugin inside Eclipse - Jetty - Codehaus や、Maher TEBOURBI Blog: Debugging maven web application with eclipse を読むと Eclipse では Maven を用いてデバッグが出来ているようだ。
ということで、jetty の設定ファイルやプラグインを修正すればデバッグも出来るようになりそうだ。しかし、めんどくさそうなので開発は glassfish や tomcat を使った方が早いかもしれない。
ところで、そもそも Jetty をインストールした理由は glassfish や tomcat では、JSP/Servlet で ServletException が発生したとき web.xml に記述した error.html が表示されるはずなのに、表示されないが、これは jetty でも同様に発生するのか調べるためだった。
Servlet/JSP でのエラーページの表示 その4 に続く。
NetBeans の main/contrib をビルドするには？ その 4 [IC]
NetBeans の main/contrib をビルドするには？ その 3 の続き。
オプションを付け忘れていたのでビルドに失敗するかなと思ったが、何とか成功した模様。
netbeans:
[genlist] Generating information for Auto Update...
[nbmerge] N:\tmp\main\nbbuild\netbeans
[nbmerge] builtmodules=[ide.ergonomics]
[nbmerge] builttargets=[-jdk-pre-preinit, -jdk-preinit, -jdk-warn, -jdk-presetdef-basic, -jdk-default, -jdk-init, -load-build-properties, bootstrap, init-module-list, set-buildnumber, init-tasks, in
it, all-ide.ergonomics]
[touch] Creating N:\tmp\main\nbbuild\netbeans\nb.cluster.ergonomics.built
create-license-summary:
[createlicensesummary] N:\tmp\main\nbbuild\netbeans\THIRDPARTYLICENSE-generated.txt: written
[createlicensesummary] N:\tmp\main\nbbuild\build\createlicensesummary.xml: 0 failures out of 1 tests
build-nozip:
[mkdir] Created dir: N:\tmp\main\nbbuild\netbeans\bin
[copy] Copying 1 file to N:\tmp\main\nbbuild\netbeans\bin
[copy] Copying 1 file to N:\tmp\main\nbbuild\netbeans\bin
[mkdir] Created dir: N:\tmp\main\nbbuild\netbeans\etc
[copy] Copying 1 file to N:\tmp\main\nbbuild\netbeans\etc
[copy] Copying 1 file to N:\tmp\main\nbbuild\netbeans\etc
[echo] N:\tmp\main\nbbuild\netbeans/platform9/lib/nbexec
[copy] Copying 1 file to N:\tmp\main\nbbuild\netbeans\nb6.5
BUILD SUCCESSFUL
Total time: 73 minutes 56 seconds
ビルドが完了するまでに約 73分かかっているけどね！しかもこの時間はビルドプロセスが開始されると始めに実行されるバイナリファイルのダウンロード時間を除いて！時間がかかるのは最初だけだが大変だ。もっとも、NetBeans の規模を考えるとビルドは速いと思うべきかもしれない。
ちなみに、ビルドした環境は Athron XP 2500、RAM：1.5G。ハードディスクの空き容量は 30G 位あった方がよさそう。
さて、ここまでは NetBeans のビルド。 次は j2ee.jetty プラグインのビルドをする。
N:\tmp\main\contrib\j2ee.jetty>ant -Dpermit.jdk6.builds=true
として待つこと 17 秒。
BUILD SUCCESSFUL
Total time: 15 seconds
の文字が。
jar ファイルは私の環境では
[jarwithmoduleattributes] Building jar: N:\tmp\main\nbbuild\netbeans\extra\modules\org-netbeans-modules-j2ee-jetty.jar
に生成された模様。...あれ？ jar ? nbm ではなくて？
NetBeans を使えばプロジェクトから mbm を作成できるとどこかの blog で読んだ気がしたので j2ee.jetty のプロジェクトを NetBeans で開きプロジェクトエクスプローラで右クリックすると【NBMの作成】メニューが見つかる。
実行すると、 java 5 を使ってねというメッセージが表示されたので、-Dpermit.jdk6.builds=true のオプションを付けなければならないようだ。
NetBeans でビルドするときに -Dpermit.jdk6.builds=true を指定するにはプロジェクトプロパティで指定する。この様子を次図に示す。
-Dpermit.jdk6.builds=true の場合、キーは permit.jdk6.builds で値が true になる。
それを設定して NBM を作成してみたところ、やっと成功。
せっかくなので作成した NBM を org-netbeans-modules-j2ee-jetty.nbm に置いておく。
プラグインを作ってくれた novakim 氏（main/contrib/j2ee.jetty）に感謝！（I wish to express my gratitude for the contribution of novakim for making plugin of j2ee.jetty.）
※私はビルドの仕方を blog に書て nbm を ビルドして SkyDrive に置いただけ。念のため。
NetBeans で Jetty プラグインを利用するには？その 2 に続く。
