やっとT2Frameworkに本腰を入れるようだ

先に言っておきます。外野からちょっときついことを好き勝手にいいます。

http://d.hatena.ne.jp/shot6/20090615#1245060150

T2を追ってきた人はたぶんみんな思ってたと思う。ここ最近は周辺プロダクトの話ばかりしていて肝心のコアプロダクトが進んでいない。1.0がいまだにでていないのです。個人的にはAMFにしろそんなのは後付でかまわないのでHTTPとHTMLをまずはしっかり動くものを1.0としてリリースしてほしかった。まずはどういったURL、どういったアクションでどんな動きになるかがシンプルに理解できるものとしてのサンプルもほしい。アクションメソッドが呼ばれる前にどのようにはさめて、Viewに行く前にどういうのが差し込めるか、後処理をやるタイミングはどこか、バリデーションを自前で差し込めるのかなど。

そしてこの基本部分以外はプラグインによる拡張でよいのだと。もちろん標準で用意されるのもいいけど、それはあくまでもリファレンス的なプラグインとなるべきかなと。「このソースを参考にしてもらって他のコネクタもみんな作ろうよ!」そんな動きがほしかった。エコシステムがまわることを重視して。逆に言えばプラグインとしての実装になっていないのならばあまりよろしくない。つまり、拡張性がないということになってしまう。



実際アクション系のフレームワークの中では、T2はURLとアクションのマッピングが一番美しく、わかりやすい。だからこそ応援しているのだが、その一方でこんな基本的なところが抜け落ちている。

http://d.hatena.ne.jp/shot6/20090615#1245047678

そもそもこれじゃ解決方法になっていない。通りすがりさんのコードこそが本来の動きだと思ってる。こういうところを放っておいて周辺プロダクトの話ばかりしているので正直、あと2、3年たてば1.0がやっとでるかなぁと思ってました。そしてそのときには周辺プロダクト含めて肥大化していて、当初のシンプルな構成はおそらく影を潜めてるのかもとか。



周辺プロダクトに力を入れるくらいリソースが有り余ってるなら別にいいんですけどね。でもとてもそうは思えない。

何より危険なのが、自作のフレームワークやライブラリはかわいいわけですよ。そして他のコンテナやデータアクセスフレームワークが使えるんですよ、といいつつ自分のかわいいプロダクトばかり前面にだしすぎないか、それが心配でした。実際やはりメインはLucyでした。Webフレームワークはわりと変更はさせやすいのですが、ビジネスロジックに影響するDIコンテナやデータアクセスフレームワークを変更するのはかなり大変なのですよ。各自テストの方法やら開発手法が確立しやすい。Webフレームワークはどうやっても一長一短になるのでとんがったコンセプトで勝負すればよい。変更が容易なのはここだけ。

今からコンテナも自作してSeasar2Guice、Springに対抗するにはかなり無理があると思います。これらのプロダクトが今の地位を得るまでどれだけのお金を消費したか。データアクセスにしてもS2DAOS2JDBC、EclipseLink、HibernateiBatis等々とはたして正面から太刀打ちができるものを作れるのでしょうか。こういった部分は一度作ったら作りっぱなしというわけにはいかなくて、メンテが延々とされる必要があります。これは大変なことです。

個人的にはLucyではなく、SimpleAdapterをデフォルト動作にしてデフォルトコンストラクタで生成、つまり何もしてないStrutsのようなものでいいわけですよ。せいぜい、Injectアノテーションで他のPOJOを注入できるようにするくらい。実態クラスのみのフィールドインジェクションでいいわけです。Lucyは立ち位置が中途半端すぎる。少なくともhelloを表示するサンプルだけでLucyを追わないといけないというのはどうにも納得がいきません。


ここはCubby 2.0にも一部当てはまります。現在Guice対応がSeasar2対応とSpring対応に比べてひどすぎます。中立的なコンテナなしがデフォルトだとテストしやすいのではないでしょうか。あるフレームワークを試すのにコンテナ必須というのも敷居は高いものですよ。コンテナを息を吸うように使ってきた人はわからないかもしれませんけど。

たとえば逆に一番力を入れたサポートがGuiceだったとします。フレームワークのサンプルはGuiceばかり。Guiceを知ってる人はいいですけど、Seasar2やSpringしか知らない人にとっては敷居が高いですよね?サンプルコード等でフレームワークのみを見てもらいたい場合、DIコンテナやデータアクセスのサンプルも結構ですが、それらが邪魔になる場合も多いかと思います。実際Cubbyのサンプルコードは敷居は決して低くありません。Strutsはたしかにたるいですけど、Strutsだけ見ていればいいのでやはりそこは楽です。


周辺プロダクトは1.0になってから力を入れればよいのではないでしょうか。もしくはあってもいいですけど、やはり専任が必要だと思います。



好き勝手いってすみませんが、きつくいうのはそれだけ期待しているからです。おいらがバージョン3時代からNetBeansにどれだけぼろくそいってきたか(^-^;

集中したT2の今後に期待してます。T2Frameworkに本当に本腰を入れて前進したときには一通り実装した後でプラグインのソースを寄贈しますよ。