Hatena::Groupangelos

Angelos in Action RSSフィード

Fork me on GitHub
 | 

2009-01-22

Angelosが参考にしているフレームワークやモジュール

03:09 | Angelosが参考にしているフレームワークやモジュール - Angelos in Action を含むブックマーク はてなブックマーク - Angelosが参考にしているフレームワークやモジュール - Angelos in Action Angelosが参考にしているフレームワークやモジュール - Angelos in Action のブックマークコメント

Angelosを作る上で、かなり多くのフレームワークのコードを参考にしています。

を参考にしています。

それぞれのWAFとモジュールから、具体的には以下のようにいいところを取り込んでいます。

  • WAFコア部分
    • コア
    • 拡張
      • プラグインの機構は、Devel::REPL
      • Pluginのフックポイントは、Sledge, Catalystから
      • Controllerの仕組み(filterやクラス構成など)はMerb
        • Merbには全体的にかなり強い影響をうけています。
      • Middlewareは、Rack、App::Mobirc
  • その他
    • CLI用のスクリプトはJifty
      • App::CLIをApp::Cmdにおきかえて、App::CLIに不足しているところを追加で実装してます
    • Helperは、Module::Setup
      • Module::Setupベースにすることで、将来的に簡単にhelperが作れるようになります
    • 認証
      • まだないのですが、あまりどのフレームワークにも決定的なものはないなぁという印象です。中ではCatalystが一番よくできています。それとMerbのRouteに対する認証機構はとてもいいので、あれを組み込むのが一つの理想型なのかなと思っています。

このうえで、

  • CLI、JobQueue、Webからモデル、Config、Logger、I18の仕組みを共有できる環境を提供する
    • これについては、他のフレームワークでもそんなに考えられていないという印象です。
  • 小メモリ、高速

というWAFを作りたいなと思っています。

# この1ヶ月で夜帰ってきてからの1-2時間と週末の時間を使って、ざっくりWAFを作ってみたのですが、全体的にはいいものになってきてるかなという印象です。気長にやっていきたいですね。

プラグイン機構

01:14 | プラグイン機構 - Angelos in Action を含むブックマーク はてなブックマーク - プラグイン機構 - Angelos in Action プラグイン機構 - Angelos in Action のブックマークコメント

最終的に、

  • BootLoader
  • Engine
  • Controller
  • View

にそれぞれフックを作って、それぞれにプラグインをもたせる形の実装になりました。BootLoaderという、新たに全体のsetup部分にhookできるのを追加したというのが前回からの追加事項になります。

この場合のデザインの悩みどころは、複数のレベルのポイントにするフックを使いたくなることがあるんじゃないか?ということだったんですが、現実的にはほとんどのプラグインはそのようなフックは不要そうです。

仮に必要になっても、複数のプラグインを組み合わせるという事で実現できるかなと思ってます。今のところは必要になるケースはでてきてないのですが。

Angelos::Middleware

00:40 | Angelos::Middleware - Angelos in Action を含むブックマーク はてなブックマーク - Angelos::Middleware - Angelos in Action Angelos::Middleware - Angelos in Action のブックマークコメント

HTTP::EngineのMiddleware仕様が固まるまでは、しばらくAngelos::Middlewareのnamespaceでやってこうかなと思って作ってます。

自分がほしいものは、大体作ってみたかなぁという印象です。リクエストにメソッド生やす系と、リクエストのライフサイクルのフック系全般がMiddlewareになるという形になっています。

今、Angelos::Middlewareにあるのは、以下のMiddlewareです。MiddlewareはYAMLの定義に順に書いて、その順にMiddleware::BuilderでMiddlewareを組み立てて、request handlerをwrapしていく形の構成になっています。

|-- DebugRequest.pm
|-- MobileAgent.pm
|-- MobileJP.pm
|-- Profile.pm
|-- Session
|   `-- Builder.pm
|-- Session.pm
|-- Static.pm
`-- Unicode.pm

Sessionは最後まで悩んだのですが、Middlewareでrequestにsessionをはやして、フレームワーク側でさらにそれをラップして触る形にしました。

ここらはRailsMerbでもそうなのですが、RackのMiddleware化するというのは、Middlewareのプロトコルにしたがった実装を用意するという形になっているだけで、RackのMiddlewareをそのまま使うという話ではないようですね。なかなか完全にどのフレームワークでも使いたい形で実装を共通化してもつのは難しいからなのだろうなとは思います。

Middlewareとしては、おそらくフレームワーク毎に実装をもって、その中で実装を洗練させながら、いいものをHTTP::Engine::Middlewareの中に抽象化してとりこんでいくのがいいんだろうなという気がしています。

以下がAPIの変更がdone

22:52 | 以下がAPIの変更がdone - Angelos in Action を含むブックマーク はてなブックマーク - 以下がAPIの変更がdone - Angelos in Action 以下がAPIの変更がdone - Angelos in Action のブックマークコメント

  • Session系をMiddlewareに移行
  • renderメソッドでviewの自動推定 from format
  • renderの引数を変更
  • contextをControllerのメソッドに渡さないように
  • BootLoaderをつくり、setup処理にhookできるように

これでユーザーからはこれでcontextは直接さわる必要はなくなった。開発者からも隠蔽すべきかは悩みどころ。

プラグイン開発者はコンテキストのデータとフックポイントだけみればいいという状況を作り出した方がいいんじゃないかというのが、contextを残したほうがいいのではないかという理由なのだけれど。

最後の大きな変更があるとすれば、contextの扱いとHookpointに渡すデータの絞り込み。どうするかなぁといったところ。もう少し考える事に。

 |