PHPのテクメモ

画面上でマウスカーソルをあわせると、小さなポップアップで簡単な説明を表示させるようなインターフェイスは結構受けがいい。こういうインターフェイスは「tooltip」というらしい。jQueryではこれを実現するためのプラグインが多数存在する。今回案件でイメージマップを作成し、その中のリンク要素に対してポップアップで見出しをつけることを提案した。しかしこれ、意外に難しくて、普通のプラグインでは対応できなかった。なぜなら表示される要素（<img>）とリンクを記述する要素（<map>）がそもそも別の場所に記述されているからだ。リンクが記述されている<map>内の<area>タグでtooltipを表示するよう記述してみたけど、思った場所に表示されなかった。自前で実装するしかない。

ここでjQueryでマウス位置を取得する必要がある。リンクエリアの入った瞬間のHTMLの左上隅からの座標を取得することさえ出来れば、そこに絶対位置指定でポップアップを表示させればいいからだ。しかしこれも単純にはいかなかったので、少し変化球で勝負してみた。

1. マウス位置は常に取得して特定の変数に格納し続ける（マウスが動いている間は絶えず）。
2. 特定のエリアに入ったときに、上記で格納している変数の値を読み取る。

特定のエリアに入ったときにマウスカーソルの位置を直接取得するのではなく、マウスカーソルの位置座標は常に変数に格納しておき、特定のエリアに入った時だけ変数を呼び出すような手法をとった（間接的）。これでうまく位置座標が取得できた。jQueryで記述するとこんな感じ。

var X,Y;
$(document).ready(function(){
$(‘html’).mouseover(function(ev){
X=ev.pageX;
Y=ev.pageY;
});
});

これで常にXとYにマウス位置が格納されているので、イベントに応じてそれらの変数値を読み取ればいい。

数年前にWordPress muがリリースされた。muはマルチユーザの略だと思うが、これ単体でMovable Typeのように複数のブログを管理することができていた。「そういえば最近muの話題を聞かないなぁ」と思っていたら、開けてびっくり玉手箱。WordPress本体に組み込まれていた。詳しい説明はこちら。

http://wpdocs.sourceforge.jp/WordPress_MU

設定方法等は上記ページに譲るとして・・・もうちょっと早く知っていれば複数設置しなくてもよかったなぁ、と思う今日このごろであった。

ワードプレスの素晴らしいプラグインを見つけたのでメモしておく。「Custom Field Template plugin」。

CMS用途でワードプレスを使用する場合、カスタムフィールドはとても便利な機能だ。しかし通常の使い方であればカスタムフィールドを設定する場合、自分で使用したいカスタムフィールド名を入力し（もしくは選択し）、その値を入力しなくてはいけない。これだとカスタムフィールドの設定をやり忘れてしまうこともあるだろう。そういう問題を解決してくれるプラグインが「Custom Field Template plugin」だ。

http://wpgogo.com/development/custom-field-template.html

このプラグインを使用すると、あらかじめ設定しておいたカスタムフィールド群を、投稿作成時に呼び出して記事を作成することができる。つまり入力が必要な項目を一括して呼び出せるので、「入力忘れ」が発生しにくいのだ。そしてそれだけではなく、もっとたくさんの便利機能が備えられている。

カスタムフィールドは通常ただのテキストフィールドだが、このプラグインを使うとラジオボタンやチェックボックス、tinymceテキストエリアからファイルのアップロードまでいろいろサポートされているし、テンプレートの複数登録も可能。またテンプレートを特定のカテゴリに割り当てておき、当該カテゴリ選択時に自動的にテンプレートが呼び出されるなど、至れり尽くせりだ。さらに日付の設定機能（Date Pickerつき）もあるし、投稿だけでなく記事にも対応しているし、果てはPHP直書きもできるし。

こんな実用的なプラグインを提供してくれた開発者に感謝。

もはやシステム開発とデータベースは切り離せないほど密接な関係があるといっても過言ではない。それ故、中途半端な知識でデータベースを使うと、あとで苦労することが多い。たかだか1000件とかその程度のデータであれば、問題ないのだが、データ件数が数万件とか超えてくると飛躍的にクエリの実行速度が遅くなってくる。

自分でも数年前までは、大量のデータを扱うような経験がなかったので、結果としてひどいアプリを作ってしまったことがある（幸か不幸か修正開発の機会を与えていただき、全て再開発した経緯がある）。だから他の人の事をとやかく言えないのであるが・・・。数百人も社員がいる会社でそういうことされると結構困ってしまう。そんな会社ダメでしょう、って感じ。

今担当している案件がまさにそんな感じ。データベースの設計がとにかくひどくて、そもそも正規化が出来ていない。相手はPostgreSQL。さぁ、どうしようかな、と悩める日々だ。そこでいろいろ思案中だったのだが、インデックスの使われ方ということで、古い記事ではあるが有意義な情報を見つけたのでメモしておく。

http://ml.postgresql.jp/pipermail/pgsql-jp/2003-February/004169.html

PostgreSQLでのインデックスの使われ方等で非常に勉強になる記事だ。知っている人なら知っているそうそうたる顔ぶれがディスカッションしている。これ見て少し勉強してみることにする。

何を今更という感じだが、わかっているようでわかっていないクッキー（cookie）のおさらいをしてみた。まずPHPでセットしたクッキーについて調べてみた。

PHPでクッキーをセット（setcookie）すると、その情報はHTTPヘッダとしてブラウザに送出される。HTTPヘッダとして送出するための関数であるから、その関数よりも前に、ブラウザに対してはヘッダ以外の情報を出力しているとエラーになる。出力するHTTPヘッダーはこんな感じになっていた（この例はsetcookieではなくセッション開始の例）。

HTTP/1.1 200 OK
Date: Thu, 11 Nov 2010 01:26:46 GMT
Server: Apache
Set-Cookie: PHPSESSID=i7y59fnv2cphp1kf76bdodu4t8ii6elk; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2402
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

ブラウザに対してSet-Cookieヘッダを送っている。ちなみにsetcookie関数ではなく、header関数で直接上記の文字列を送出しても問題ないはずだ（試していないけれど）。送出された情報を見ると、値（この場合はセッションID）、パス、HttoOnly、期限（ブラウザを閉じるまで）の情報が送られている。またクッキーはデフォルトで、当該ホストとのみやりとり可能なので、アクセスしたホスト名に限定したクッキーとなっているはずだ。

サーバから上記のヘッダを送出されると、ブラウザを閉じない限り当該ホストに関して、ブラウザは今後永久に（クッキーの削除でもしない限り）、Cookieリクエストを送出するようになる。リクエストの例はこちら。

GET /dummy.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 GTB7.1 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: text/css,*/*;q=0.1
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.example.com/
Cookie: PHPSESSID=i7y59fnv2cphp1kf76bdodu4t8ii6elk

/dummy.htmlをリクエストした例だ。リクエストの最後に、先程受信したクッキーを送出しているのが見て取れる。一旦クッキーをセットされると、ブラウザが閉じられるかそのクッキーが削除されるか有効期限が切れるまでは、ブラウザは当該ホストに対して必ずクッキー付きでリクエストを送るようになる。

以下は、/dummy.html内に含まれる/img/logo.pngに関するリクエストだ。

GET /img/logo.png HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 GTB7.1 ( .NET CLR 3.5.30729; .NET4.0C)
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.example.com/
Cookie: PHPSESSID=i7y59fnv2cphp1kf76bdodu4t8ii6elk

クッキーの送出は対象が何であっても関係ない。拡張子も関係ない。プログラムであろうが、HTMLであろうが、画像であろうが、音楽であろうが、ブラウザが閉じられるかそのクッキーが削除されるか有効期限が切れるまでは、ブラウザは当該ホストに対して、ずっとクッキー付きでリクエストを送り続ける（そもそもブラウザがリクエストする時点でリクエスト対象に対して「これは画像」「これはHTML」とか淡い期待をいだいているだけで、本当にそういうものが返ってくるかどうか分からないから）。

自分で整理してみて、ちょっとだけ理解できた。あとはJavaScriptによるcookieの受け渡しを調べなきゃな。