イベント機能について
2008年12月4日
現在、以前述べたリファクタリング計画を遂行中で、少しずつではあるが、すっきりしてきた。アイテム用テンプレート変数のためのメソッド（それぞれ、１－５行ほど）がitemクラスにずらっと並んだ姿は、壮観である。
さて、まだまだ先のことなのだが、イベント機能に付いて風呂でいろいろ考えていて思いついたことがあるので、それをメモ。
Nucleusのプラグインでは、イベント機能を用いることがある。当然、Jeansにもこの機能を搭載する。ところでJeansでは、先の記事で述べたようにcore, view, actionの３つの機能がハウスキーピング遺伝子として働いている。いろいろ考えた結果、イベントの発生においても、core, view, actionの３つに分けて考えた方が良いようである。まず結論としては、
１）core, viewのイベントは、種類が少なければ少ないほど良い。
２）actionのイベントは、種類が多ければ多いほど良い。
ということ。なぜか？core, viewのイベントの種類が多すぎるとどうなるかというと、必然的に速度の低下をもたらす。coreは必ず呼び出され、viewはブログの表示の際に呼び出される。サーバへのアクセスのほとんどはブログの表示だから、その場合に呼び出されるcore, viewの機能内では、イベントの数を必要最小限に絞りたい。逆にactionのイベントであるが、多すぎて弊害が出るケースは考えにくい。まず、サーバへの接続にactionを伴う頻度が低いことが一つの理由。もう一つは、それぞれのイベントはactionの種類によって異なるため、一回の接続で多数のイベントが同時に起こる訳ではないからである。
イベントに関してもう一つ押さえておきたいことは、イベントをフックするプラグインの種類をSQLテーブルで管理する際、core, view, actionの３つの種類分けもインデックスしておくこと。これにより、core, viewで必要なイベントをリストアップする際（一回のSQLクエリー発行）に、不要なaction用のデータまで取り出して時間とメモリの無駄をすることがなくなる。一方action用のイベントは、必要なときに必要なものをその都度SQLクエリーを発行して取り出せば良い。
さて、まだまだ先のことなのだが、イベント機能に付いて風呂でいろいろ考えていて思いついたことがあるので、それをメモ。
Nucleusのプラグインでは、イベント機能を用いることがある。当然、Jeansにもこの機能を搭載する。ところでJeansでは、先の記事で述べたようにcore, view, actionの３つの機能がハウスキーピング遺伝子として働いている。いろいろ考えた結果、イベントの発生においても、core, view, actionの３つに分けて考えた方が良いようである。まず結論としては、
１）core, viewのイベントは、種類が少なければ少ないほど良い。
２）actionのイベントは、種類が多ければ多いほど良い。
ということ。なぜか？core, viewのイベントの種類が多すぎるとどうなるかというと、必然的に速度の低下をもたらす。coreは必ず呼び出され、viewはブログの表示の際に呼び出される。サーバへのアクセスのほとんどはブログの表示だから、その場合に呼び出されるcore, viewの機能内では、イベントの数を必要最小限に絞りたい。逆にactionのイベントであるが、多すぎて弊害が出るケースは考えにくい。まず、サーバへの接続にactionを伴う頻度が低いことが一つの理由。もう一つは、それぞれのイベントはactionの種類によって異なるため、一回の接続で多数のイベントが同時に起こる訳ではないからである。
イベントに関してもう一つ押さえておきたいことは、イベントをフックするプラグインの種類をSQLテーブルで管理する際、core, view, actionの３つの種類分けもインデックスしておくこと。これにより、core, viewで必要なイベントをリストアップする際（一回のSQLクエリー発行）に、不要なaction用のデータまで取り出して時間とメモリの無駄をすることがなくなる。一方action用のイベントは、必要なときに必要なものをその都度SQLクエリーを発行して取り出せば良い。