NDS#25で発表しました

そこそこ反応があったので良かったです。ただ、環境まわりとか時間とか反省すべきことも多かったです。関係各位すみませんでした。次こそは時間内に収めようと思います。次回はIPv6 Hackathon in 新潟でお会いしましょう!

checkboxをチェック状態にする時の注意点

お陰様でjQueryのせいでhtml以外でUIを書きたくありません。

さて、jQueryでcheckboxをチェック状態にするには、

$("input[type='checkbox'][name='checkboxName']").val(['001','002']);

のように、1行で書けてしまいます。val()の中には配列を設定することでレスポンスの値を元にチェック状態を設定することができます。

ですが、val関数の引数にnullを設定してしまうとcheckboxのvalueが消えてしまいます。画面上は問題なさそうなのに、value値が取得できず、小一時間ハマりました。

それにしてもcheckboxの構成情報をマスタから取得して表示しつつ、テーブルから取得した値を参照しながらcheck状態にするような画面をstrutsなんかでやる時はえらく面倒だったのですが。最近も面倒なんでしょうかね?

Selectorsって便利だけど

jQueryを使う上でSelectorsは避けて通れません。これに合致する奴にイベント設定や、css付与することができ、パズルみたいでちょっと楽しかったりします。
で、今回こんな構成でaタグにクリックイベントを追加しようと思いました。

<table id="table1">
<tr>
  <td><a href="javascript:void(0)">AAA</a></td>
  <td>あいうえお</td>
</tr>
<tr>
  <td><a href="javascript:void(0)">BBB</a></td>
  <td>かきくけこ</td>
</tr>
<tr>
  <td><a href="javascript:void(0)">CCC</a></td>
  <td>さしすせそ</td>
</tr>
</table>

jQueryはこんな感じで記述。

$("#table1 a").click(function(){
  alert("押したね");
});

FireFoxで動作確認して、じゃーIEは・・・と思ったところ、IE8で動かない。IE9では動くのに・・・。
結局、Selectorsを複数の要素で使うときに先頭にid属性があるとうまく動かないようでした(ちょっと自信ないです)。
先頭にclass属性でやれば良いっぽい。tableはこんな感じ。

<table id="table1" class="table1Class">


jQueryはこんな感じで記述。

$(".table1Class a").click(function(){
  alert("押したね");
});

ブラウザ統一できねぇかな・・・。複数のバージョンで挙動が違うってのは飽きました。

イマドキのWebシステムに向けて

 最近のWebシステムは、クライアント依存しづらくしなきゃだめよねー、ということで、サーバサイドにはJava、クライアントはJSON+JavaScriptレンダリングという構成でシステム構築を考えております。そんな中で気づいた事をメモっとこうかなぁ、と。

なんでそんな構成にするの?

 PCのWebブラウザだけでなくスマフォのブラウザやネィティブなアプリに対応しやすくするためです。サーバサイド処理を変えることなくクライアント側の処理で対応させちゃおうということです。サーバサイドの処理はJavaでなくてもPHPRubyでもなんでも良いわけです。クライアント側と会話さえできれば。

サクサク感がたまらない

 今まではsubmitして画面表示しなおすという方式が当たり前だったのですが、この方式に慣れてしまうと、画面遷移がモサく感じます。何か、ボタンを押すたびに画面が切り替わってスクロールバーが一番上に戻ることに違和感を持つようになりました。
 そして、レスポンスには、必要な情報だけ返せば良いというのが気に入っています。ある部分だけ書き換えたいのに他の余計な情報まで意識してレスポンスに含めないといけなかったあの頃の俺、どうかしてるぜ、的なノリです。何ていうんでしょうか、検索条件を受け取り、検索結果を返す処理なのに、レスポンスには検索条件も含めなければならない違和感。それが無くなり、必要な情報だけ返せば良くなった、というのは処理の見通しも良くなる、ということです。


ハマらない為の工夫

処理の分散を防ぐ

 jsで判断文を書くとロジックがサーバ側とクライアント側に分散する可能性があるので、できるだけサーバサイドに処理を押し込んでjsではレンダリングに徹してもらうのが良いのではないか、と思います。どうせJSPでその辺の処理を書いていたわけですからサーバの負荷はそんなに大きくなるわけじゃないと思いますし。

サーバとの通信

 同期させてます*1。非同期にすると同期が必要な時にいろいろ制御しなきゃいけなくなりそうでしたから。同期しておけばその辺を考えなくて済みますし。全画面描画しなおすのが嫌なだけです。

なるべく状態を持たないように

 jQueryjQueryプラグイン等を使っているのですが、ソースコードを隅々まで見ているわけではないのであまりわかってませんけど、js側で「状態」を持ってしまい、それが不整合を引き起こすことが怖いので、サブメニュー単位では画面を再描画させるようにしてjsの状態を持ち続けないようにクリアしています。変数の有効範囲を狭くすることで変な所でつまづかないようにしてます。

クロスブラウザ対応

 ブラウザによる処理の違いがあります。特ににInternet Expl○rerって奴は困ったものなのですが、それでもjQueryさんとかや作り自体を変えることで対応できてます。まぁ、クロスブラウザ対応を謳ってしまえばこの構成でなくても逃げられないと思うんですけど。システムは作って終わりじゃないということで根本的な解決策は見つかってません。

まとめ

 ここまでjsに依存したWebアプリには抵抗感があったのですが、今回をきっかけに「悪くない」と思うようになりました。ビバ、js。
 サーバサイド側の処理は、JSPへの依存が薄くなった分、さらにロジックの記述に集中できるので、テストしやすくなるってもんです*2
 後は、デザインセンスが圧倒的に不足しているのが露呈されます。あぁ、俺はロジックを書くことしかできないんだな、って。いや、僕だけの問題なんですけど。「業務システムなんだから見栄えなんて二の次」なんて自分を慰めてますけどオサレなものにしたい欲求が抑えられません。デザインの本買おう。

*1:厳密にはAjaxではないんです

*2:ですが、「M」「C」と「V」の分業ができてるプロジェクトが一体どれほどあることか・・・

小悪魔女子大生のサーバーエンジニア日記

読みました。後輩クンからのありがたいプレゼントを使って購入。

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

この分野に対して情報処理技術者試験の参考書を読むよりも理解度は増します。「言葉だけ知ってる」ことを理解できたことがいくつかあって、何気に僕には為になりました。でも、手書き部分はイマドキの文字っぽくてやや抵抗アリ。

これ読み終わった後、「餅月あんこ」って今何やってるのかなーと思っちゃいました。ドラネコシアター好きだった。