garbagetown

個人の日記です

続・ルーティング

昨日 の予想 1 案が我ながらイカしているので「ルーティング周りのどっかのクラスを継承したやつを作って dicon ファイルいじったらプラグインっぽく差し替えできちゃったりして!」なんて妄想に駆られてソースコードを読んでいたのだが、意外な事実が判明した。

Action クラスの定義

Action クラスは action パッケージに属していなければならないと思い込んでいたのだが、Cubby が Action クラスとして認識する条件は以下のとおりであった。

  • ルートパッケージ配下に存在するクラスであること
  • org.seasar.cubby.action.Action クラスを継承していること
  • xxxAction というクラス名であること

action パッケージに属するクラスであることという条件はない。青天の霹靂とはこのことである。
ここで改めて Action クラスの説明 を読んでみると、たしかに action パッケージ云々という記述はどこにもない。さらに 2 分間チュートリアル のサンプルを見てみると、hello パッケージに Action クラスを定義している。
青天の霹靂でも何でもない。ぼくがドキュメントをよく読んでいないだけだ。

結論

Cubby トップページ の「Cubby のゴール」と銘打った段落には、次のように記述されている。

  • アクションクラスを見れば何をやっているのかわかる。

ややこしい命名規約を設けるくらいならソースコードに明示しようという確固たる意思が滲み出てくるような一文である。おれのアイディア超イカしているとか勘違いしてすみませんでした。
とは言え、ルートパッケージ配下を丸ごと grep しないと目的の Action クラスを探せないような @Path アノテーション濫用マッピングはどう考えてもマズいので、個人的には昨日の予想 1 案と @Path アノテーションのコンボが最強かなと思います。
それにしても、Cubby のバランス感覚を垣間見てますます気に入りました。向こう三軒両隣のご近所さんにも教えてあげようと思います。