NAME

whyyatt(ja) -- なんでやっとやんの？

DESCRIPTION

yatt はプログラマーよりも、非プログラマーである Web デザイナーの表現力をいかに強化し、 かつ安全に Web 開発の主役を任せられるようにするか? というテーマで設計されています。 Rails , Django , CakePHP など MVC 型設計をうたう最近の Web 開発フレームワークにおける役割分担では、 Controller がユーザのリクエストに対して何を表示するべきかを全て判断し、 その上で、テンプレートエンジンが Controller から受動的に呼び出される、 という設計が主流であるように思います。 つまりテンプレートエンジンは受け取ったデータを HTML へ変換する単なる部品として位置づけられ、 Controller が Web アプリの王になる設計です。 ですが Web アプリにとって本当に大事なのは ユーザにどんな HTML を届けるか であり、 むしろテンプレートエンジンこそが Web アプリの王であるべきではないでしょうか? 主流の設計で、 もしビジネスサイドから急に「画面のここにも別画面の○○を差し込んでくれ」と言われたとき、 変更が Controller にまで及ぶとしたら、それは果して良い設計なのでしょうか? (そもそも、 元々の MVC では View が Model を読むことは 許されていた のに、いつの間に Controller からしかデータを渡してはいけない事になったのでしょう?)

これとは逆に、(生の) php のように、 リクエストに対してテンプレートが真っ先に制御を受け取るタイプのシステムもあります。 これなら突発的な要求が来ても、 (モジュール化が十分済んでいれば) その呼び出しを追加するだけで済むはずですし、 最悪そこで自作することになっても、(制限付きのテンプレート言語ではなく) フルセットの php が使えるので酷い目にはあわないと予想できます。 ただし勿論、 ユーザからのリクエストの解析処理 、 (個々のページやアセット参照の可否判定など) アクセス制御 、 そして モデルへの呼び出し など、 個々のテンプレートファイルに書き散らかすと後で困るものもあるので、 ロジックの集中管理や抽象化の仕組みが大事であることには変わりありません。

そこで yatt は、

• テンプレートが上位に立ち、必要なだけ Model を叩く

• テンプレートをフルセットの perl スクリプトへ変換する、 拡張可能なコードジェネレータを活用する。

• テンプレートの手前に、ディレクトリ毎に薄い Controller 兼 ModelWrapper を置き、 そこでリクエスト解析処理と Model への呼び出しを集中管理できるようにする

というスタイルの Web アプリを支援するように設計されています。 そして行く行くは、テンプレートを書く Web デザイナーが、 プログラマーに頼らずとも自分で Web サイト・サービスのあり方を完全にコントロールできる時代を作れないか、 そういう狙いで作られています。