Teedaのメリット・デメリット


Teedaのメリット・デメリットについて振り返ってみたいと思います.


Teedaのメリット
・HTMLテンプレート

まずはなんといってもHTMLテンプレートではないでしょうか。

レイアウトを確認するうえでは威力を発揮しやすいと言えます。

また前工程でユーザに確認してもらうために作成したモックをそのまま開発に

持ち込める点は良いのではないでしょうか。


・設定ファイルレス

規約による設定ファイルレスはTeedaの中でも生産性に貢献する部分のひとつです。

簡単な規約を付与することで、設定ファイルに書くタグ+設定内容を規約に

置き換える部分は効果はあったでしょう。ただしデメリットもあります。後述します。


POJOベースのPageプログラミングモデル

POJOなPageクラスをHTMLと1対1でバインドするTeedaの方法は

役割としてはとてもわかりやすかったように思います。DoltengのHTMLとPageクラスの

移動する機能も手伝って、HTMLとPageクラスを相互に開発できる部分は効率的な開発に

大きく貢献していると言えるでしょう。


・PRGパターンによるきれいなURL

フォワードベースのフレームワークではURLがずれるのが一般的ですが、

PRGパターンを採用しているTeedaではそれは発生しません。

その点は良い点だと思います。が、デメリットもあります。


・その他多彩な機能

その他ユーザの望む機能がExtensionとしていくつも実装されてきました。

細かい使い勝手の部分などを含めると相当数あるように思います。

通常のJSF実装だけを使っているユーザはここまでの使い勝手は望めないので

おそらく相当苦労することになると思います。コンポーネントのカスタマイズを

ばしばしかけなければいけなくなるので。

その点では結構機能は提供できたと思います。Teeda AjaxもKumuもフレームワーク

提供する機能としてはとてもシンプルなものですが、よく出来ていると思ってます。

あまり依存関係も少ないですし。



次にTeedaのデメリットについてです

Teedaのデメリット

JSFが提供するライフサイクル

これについてはメリットでもある部分が多いと昔は思っていたのですが、

あまりに単一的なライフサイクルは現在では逆にデメリットのほうが多いと思いました。

つまりJSFという仕組み自体が少し癖があるのだと今では解釈してます。


・設定ファイルレスと規約

たしかに設定ファイルレスは素晴らしい機能ではあります。

しかし、規約が大量に出てくるのは頂けません。Teedaは規約を最小限にしていたつもりですが、

修正を重ねるごとにその規約の量は増えてしまったといえるでしょう。

規約ベースでのフレームワークは最初にあったシンプルな規約程度にとどめて置くのが望ましいと考えます。

また、規約はユーザがある程度自由にいじれないのであれば害があると思います。

誰しもが強制されるのを望んでいるわけではなく、ゆるい枠はありつつも、細かい部分は自分が

使いやすいようにいじりたいのだと思います。面倒なバインドはやってほしいが表層の部分は

えてして自分でやりたい、それが開発者の声なんじゃないかと思っています。

なので、自分の考えは「Convention over Configuration」よりは、「Convention with Configuration」が

今後の主流になっていくのではないかと考えます。


POJOベースのPageプログラミングモデル

Actionベースになれた人にとっては、Pageモデルはもしかしてとっつき難いかも

しれません。特にStrutsになれた人にとっては引数でFormのデータは引数で渡ってくるものだと

言う思考があるので、TeedaのPageクラスのようにいつ値がセットされているかわからない

モデルは上記のライフサイクルの件も重なりわかりにくい可能性があります。

また、Teedaは実は2回値がセットされています。1回はTeedaのライフサイクル内(JSFとして)で値がセットされます。

もう1回はSeasar2のエクスターナルバインディングによって、Pageクラスが名前ベースで引き出された

段階で既にリクエストが反映されているのです(デフォルトでは。設定でエクスターナルバインディングしない設定もできます)。

大体の場合はエクスターナルバインディングの方がライフサイクルでデータがセットされるよりも先でしょう。

Teedaのライフサイクルで値がセットされるところは予想がつきますが、名前ベースでコンポーネント

取得されて、エクスターナルバインディングされるタイミングにはある程度ばらつきがあるのが現状です。



私はリクエストのパラメータが勝手にセットされるのは現在では良くないのではと考えています。

ユーザが明示的にセットするほうがより良いし、よりわかりやすいんではないでしょうか。




・PRGパターンによるきれいなURL

PRGはPOSTとREDIRECT、GETを組み合わせる手法のひとつです。

これはきれいなURLを見せるには有効な手法ではあると思いますが、

いくつかの状況で問題になることがわかっています。

あてはまりそうなのは携帯での開発です。最近の機種では少ないかもしれませんがREDIRECTの

回数を制限している端末などがあったりします。また、PRGではリクエストを2つ消費するため、

パケット量が増大してしまう傾向にあります。きちんと測定していないのでどれくらいの

パケット量が増大するかはわかりませんが。誰か情報あれば、plz

しかし、通常JSFだと自分が知らないタグだと描画しないのですが、Teedaはそういう点に

関して言えば、自分が知らないタグでも描画するようになっているので、携帯開発が出来ないと

いうわけでは無いのですが、PRGの仕組みを考えると携帯の開発にはあまり向いていないと言えるでしょう。



・その他多彩な機能

その他多彩な機能はメリットも勿論多かったと思います。

しかし、その分デメリットも大きいのが事実です。

それは何かというと、機能過多によるコードの肥大化とユーザが本来やらなくてはいけない部分と、

フレームワークがやらなくてはいけない部分の切り分けについてです。


これは個人的にもとても勉強になった部分でした。

ユーザがやらなくてはいけない部分はユーザがやらなくてはいけない部分なのです。

元来開発をやる場合はOSSフレームワークをナマで使うのは極力避けるというのが

自分の昔からのポリシだったのですが、いつのまにかそれを忘れていたようです。心より恥じる。

なので、ユーザはOSSフレームワークを上手にシンプルに使って、その上に自分たちのフレームワーク

載せて開発するのが最も望ましい姿なんじゃないかと自分は思います。

なので、OSSフレームワークにそんなに大量の機能は必要なく、シンプルに小さな機能を実装しておけば

いいんじゃないでしょうか。いつでもちょっと足りないくらいがちょうど良いんです。

そういう意味で言うとTeedaはやや機能過多だなあとは思います。反省。




あとはデバッグの追いやすさ・保守性のし易さ・明示性などそういうところを考えたフレームワークって

どんなんだろうと最近では妄想はしてたりします。なんかそんなにいっぱい機能あっても

ユーザが本当に何を求めているのかってわからないので、面倒くさくて煩雑なところだけきちんと解決して、

あとは各自作ってくのが一番良いんじゃないでしょうか。WebフレームワークでもDaoフレームワークでも

それってバインドするところなんじゃないでしょうか。そこさえ凄く上手くやってくれればって気がする。

その辺をしっかり考えて行って、形にします。

続Teedaのメリット・デメリット

大体同意見ですが、私にとって最大の誤算は、開発者のJSFアレルギーですね。
JSFアレルギーというより、新しい技術に対するアレルギーといったほうが正しいかもしれません。

それも間違ってるかな。DIみたいな小難しい技術もそれなりに受け入れられているから。

あえていうなら、ブラックボックス感のある技術に対するアレルギーでしょうか。
ブラックボックス感があるというのは、実際の動きが予想しづらい、
分厚い仕様であるということです。

そのとおりだと思います。

ブラックボックス感がどうしても出てしまう技術より、機能最小だけど自分でメンテナンスできる

ほうが私自身も良いと思っています。

そういう意味ではTeedaはどうがんばってもブラックボックスですね。

中身を見るにはそれなりにJSFの知識が必要なのは否めません。

とはいえ、Teedaスタイルのリッチな機能の提供もやれるところまでやってみても
いいのかなという気持ちもあります。

金曜日に、小林さんから、Teedaの拡張案を聞いたんですけど、結構すごい。
Entityと直接バインディングできるようになるので、永続化されないプロパティ以外は、
プロパティを宣言する必要がなくなります。S2Dxoも使う必要がなくなるということです。
詳しくは、小林さんが語ってくれるでしょう。


自分はこれ以上Teedaをリッチにしなくても良いんではと思います。

世の中にあるリッチな感じのやつってそこまで求められているのかがとても疑問なので。

リッチの意味が違うかもしれませんがw

しかし、Entityをやりとりするのは良いかもしれないですね。

おそらくELとリゾルバの部分を修正するんでしょうか。


Teedaに関しての自分の役割はきちんとチュートリアルを仕上げること、

書籍がもし出るならばそれを完成させることですかね。

続々Teedaのメリット・デメリット


id:habuakihiroさんのところで、かなり腑に落ちた感じです。

要するに「いいじゃん、これで」って思えるほどほど感がほしいんですね。
足りないくらいがちょうどいい。あとは自分たちの都合でどうにかするから。
最初から考え抜いた仕様ってのは、現場では無理があるわけで。

ひとつずつのプロダクトはちょっと足りないくらいでよくて、
それが出来るだけ個別にバラバラであるほうが部品としてのレバレッジが利く。
変にスタックを意識されていると困る。それはスタックスィートを否定してるんではなくて、
部品の観点とは別に進められるべきだということです。
JSFやEJBは部品としてはでかすぎるのでレバレッジが利かない。


個々のプロダクトを小さくシンプルに保つという意味では、

この点はとても重要ですね。またスタックと部品の観点はそれでよいのだというの納得感があります。

「スタックとして優れること」と、「部品として優れること」、は

提供形態も異なるし、訴えたいポイントも異なってくるだろうから、

そこは分割すべきという点は同意です。


また、実際JSFという実装を作ってみた感想を付け加えると、JSFは仕様が複雑です。間違いない。

部品としてレバレッジを効かすには仕様が大きすぎる感は否めないです。

賛否両論ありますが、Servlet仕様くらいの小さな仕様で良いんじゃないかというのが個人的な結論。

JSFは大風呂敷すぎるんですよね。Webに絞り込んだわけではないという記述があったり、

携帯対応やその他HTTPに依存しないようにとかなり広範囲にサポートしなくてはいけないあたりがかなり悩ましい。

BeansあればS2Dxoイラネっていうなら、だったらコンテナに入っていてほしくないわけです。
逆にS2Dao使ってれば新しいS2JDBCなんていらんのでコンテナに入っていてほしくない。
コンテナそのもののメンテナンスでバージョンが上がるのか、
DxoやJDBCなどのために上がるのかという切り分けが出来ない。
使ってない部分のためにバージョンをあげるのはリスクです。
部品としてのレバレッジが弱いというのはそういうことです。


これにも同意かな。

少なくとも部品のレバレッジ効かすって観点は重要だとは思う。

部品を組み合わせるメリット・デメリットと、あらかじめパッケージングして

配布するメリット・デメリットのバランスについてのひがさんと羽生さんの意見の相違だとは思いますけどね。

全部パッケージングして配るというのには、S2.4を使っているならS2JDBCを使ってよという明確な意図があるとは思う。

逆に全部部品ばらばらでそれを組み立てる初期コストがあまりに大きいのであれば、

そこはパッケージで提供して欲しいと思うだろうし。