Teedaのサンプルアプリを読んでみる(4)
次はtodoList.htmlのPageクラスTodoListPage。このクラスはAbstractTodoPageのサブクラスで、それはさらにAbstractCrudPageのサブクラスとなっている。パッケージ名まで含めて表すと次にようになる。
java.lang.Object | +-- jp.co.gihyo.javaexpert.todo.web.AbstractCrudPage | +-- jp.co.gihyo.javaexpert.todo.web.todo.AbstractTodoPage | +-- jp.co.gihyo.javaexpert.todo.web.todo.TodoListPage
このパッケージ名やクラス名の命名規約についてはSMART deployの「パッケージの構成」とか「パッケージ構成サンプル」あたりが参考になる。
「パッケージの構成」に従うとjp.co.gihyo.javaexpert.todoがこのサンプルのルートパッケージ。次のwebは個別パッケージの１つでサブアプリケーションのルートになる。AbstractTodoPage/AbstractCrudPageにある2つめのtodoはサブアプリケーションの名前(todoという名前が2回出てくるのは、サンプルとしてアレゲな気がするけど、後述の命名規約に従っているわけだから仕方ないのか)。さらにパッケージの要素を見ると、このtodo下のTodoListPageなど"Page"で終わるクラスは、HTMLに関連付けられたもの。そのHTMLファイルは/vew/サブアプリケーションの下へ配置することになるらしい。でもAbstractTodoPageはその名のとおり抽象クラスでインスタンス化できないからHTMLと無関係。
さらにこのクラス/ファイル名も命名規約が決まっている。それによると
サブアプリ名はテーブル名が小文字で入ります。サブアプリ内のクラス名の先頭にはサブアプリ名が入ります。Pageクラス名には、対応するHtmlファイル名が入ります。
とするらしい。しかしこのページの上の方では「サブアプリケーション = ユースケース」という説明しているので、なんかしっくり来ない。ユースケースとテーブル名はそんなに密な関係を持っているのか？なんて考えても相手が規約なんだから無意味。こちらは従うだけだ。
で、命名規約の表を見ると、その画面の機能によって
- テーブル名 + "List.html"
- テーブル名 + "Edit.html"
- テーブル名 + "Confirm.html"
とするらしい。やはりテーブルと操作内容が密な関係を持ってるのね。でも複数のテーブルを結合させて得られる結果を１レコード毎に見せる画面は、規約上なんて名前にすればいいんだろうね。そう考えると規約という割にはアレだね。
次はPageのクラス名。これもテーブル名がキーになっている。それによるとHogeというテーブルを操作するアプリケーションを作るには、まずHogeテーブルの全カラムに対応するフィールドを定義したAbstractHogePageというクラスをhogeパッケージに定義しておく。で、一覧表示するPageに対応するクラスは、HogeListPage(=テーブル名 + "ListPage")という名前で、上記(AbstractHogePageといった)テーブルのカラムを持つクラスを継承する、というのも規約なのか。
最後にwebの直下に
- AbstractCrudPage
- CrudType
を配置する。そしてAbstractHogePageは、このAbstractCrudPageを継承するというのが規約か。これは各サブアプリケーションに共通するのでweb下にある。
SMART deployの冒頭には
Seasar2.4から奨励されているパッケージ構成等の規約を守る事によって、設定ファイルを追記する必要なく開発を行うことができます。
とあるけど、この規約はChuraと呼ばれているんだよね？でもこのページにはChuraという言葉は一切出てこないし、リンクもない。そして
とあるんので、DoltengはChuraに準拠なんだろう。ということはクラス名も↑の命名規約に従わないとDIされないのか？「規約に従えば自動でやります」というのはいいけど、その規約はどこかに成文化されてないのかね。まぁ実際やってみればわかるんだろうけど、それじゃ効率悪いよな。開発者って「できます」なんていうカタログ的なことより、「どこまでできるのか？」といった限界を知りたがるような気がする。「できる」ことより「できない」ことの証明の方が難しいからね。
