■
id:koichikさんの日記（これ）に反応。
単純なフレームワークは理解するのは簡単かもしれない．
しかし，手間が少ないという意味の簡単さはもたらしてくれないかもしれない．
なんてことを，Click のサンプルを見て思ったり (人によっては「コード書いてる感」が味わえて楽しいそうですが)．
フレームワーク側でアプリケーションの手間を減らせるものなら減らしてあげたい．
それによってフレームワークは複雑になるかもしれない．
それはトレードオフかもしれない．
もしトレードオフだったらどこでバランスを取るか？
これは確かにトレードオフだと思います。
ユーザの利便性を追及していくと、どうしてもフレームワーク側で対処しなくちゃいけない事が増えます。
しかし、それがフレームワーク自体の内部構造を複雑にしてしまうことは事実でしょう。
これってその作る人・使う人の立ち位置によっても見え方が変わると思います。
例えば、シンプルなフレームワークは一般的にフレームワーク開発者には喜ばれそうです。
何故かと言うと組み込みやすいから。
機能足りなくても、足せばいいじゃん。組み込んじゃえばいいじゃんで済むので。
ただ世の中そういう意見の人ばかりではありません。
何かの記事で読んだのですが、Railsは内部構造が多少汚くなっても出来る限り
フレームワーク側で処理してユーザの手数を減らして効率的にしてユーザの手数を減らすことを
目的としているようです。Railsは既にフルスタックで一通り揃っているのでそのままユーザが
使って開発できることを目指しているのでしょう。間違ってたら教えてください＞Railsな人
このようにどこに軸足を置いているかでずいぶんその使い方も変わります。
これは各フレームワークのポリシーなので、それぞれのあり方があっていいんじゃないかと思います。
自分はポリシーが見えるフレームワークは好きですね。使うかどうかはともかくとして。
こういうポリシーがあるフレームワークはopinionated-frameworkとか呼ぶそうです。
自分は確かTapestryでこの言葉を知りました。例えばTapestryもHLSさんがかなりのツワモノなので、
強いポリシーのもとガッチリ作られています。
ただ実際の現場では、このポリシーの違いを意識できていないと思わぬところで
足止めを食ったりします。優秀なフレームワーク開発者があれとこれとそれで、ポリシーの違いを
吸収できる層をもうけてささっと作れればそれはよいことですが、普通のエンジニアでも
人手不足の時代にいつもそうできるとは限らないわけです。
というわけで、フルスタックなフレームワーク、つまりポリシーに一貫性があるフレームワークは
、経済性・効率性・利便性の面でも最近の世の中の流れだというのも納得できます。
手前味噌なTeedaではどうかというと、フレームワーク側でなるべく対処のポリシーですね。
これはChuraとしてそうなので、Teedaだけの話ではないですけど。
JSFとしてもどちらかというと、そういう匂いをかなり感じます。
もともとコンポーネントのカスタマイズの敷居はそれなりに高いので、誰にでも門戸が開かれているような作りにはなってません。
がしがし書けばそりゃあ出来るけどねえって感じ。
JSFの拡張性に関してはそれなりに思うところはあります、正直。
（もしかしてこの辺はTeedaでは対処できる余地があるのかなあとも思う）
例えばMyFacesも、かなりリッチに色んなコンポーネントが存在します。
正直よくこんなに作ったなあーって関心するくらいある。
フレームワーク側でなるべく対処となると、やるべきことが爆発的に増えます。
本当に山のようにあるしｗ
色んなユーザビリティの部分でも、もっとやれることはあるのです。
■
某巨大掲示板を久々にみてみました。遅すぎですまそ、つーか某巨大掲示板あまりみないっす。
265さんのまとめから。
まとめということで、249-251の意見を中心にまとめると、3行以内の短い日本語で書かれた説明があり、
ドキュメントとサンプルコードがいっぱいあれば嬉しいと。名前は判り易いにこしたことないけど何でも良いと。
で、3行以内の日本語で書かれた説明はだいたいあるね、トップページに1行説明もあるし。
で、ドキュメントとサンプルコードも主要なのはだいたいあるね。理解できるかどうか別にして。
だから真に必要なのは、見やすいサイト構成とｦﾏｲﾗにも判る優しい基礎技術の説明も含めた手取り足取りな
ドキュメントと仕事でそのまま使えてｺﾋﾟﾍﾟで仕事終わらせられるサンプルコードでOK?
ごもっとも。Teedaのドキュメントに関しては本当に申し訳ない。
Teedaのドキュメントは2月に作りこむ予定です。
その中には、
・Teedaの概略・ポリシー、S2JSFとの違い
・各一つ一つのコンポーネントの説明と使い方（コンポーネントショウケース）
・サイト構成の見直し
・サンプルアプリケーション
という感じにしていく予定。
コンポーネントショウケースは実際に動いているコンポーネントと、そのソース、
使い方がタブで切り替えられるような感じにする予定。
まだSeasarのサーバーチームの人に了承もらってないんですけど、やりたいしやる方向でいます。
265さん、まとめありがとうございますｍ（＿ ＿）ｍ
