My favorites | Sign in
t-2
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
Policy  

ja, en
Updated Mar 24, 2011 by shinpei.ohtani@gmail.com

ポリシー

T2がやること (Things T2 does.)

-Webにつながること -Connect to the WEB-

T2はWebにつながる・つなげる部分に特化したWebフレームワークです. Webフレームワークのコア部分であるクライアントから来たHTTPリクエストを処理する接続部分にこだわって作成されています.

Viewは原則選びませんが、それ以外のことはなるべくやらないように意図的に設計されています. T2はそれ単体で使われることだけでなく、使って下さるユーザさんが自由にその上に独自のフレームワークを 重ねやすいようにしています.

-ステートレスを基本方針とする

T2はステートレスなフレームワークです. ここでいうステートレスとはなるべくフレームワーク側で状態を持たないという意味です. なぜステートレスにしたかというと、ステートレスなフレームワークはステートフルなフレームワークのミニマルセットだからです. ステートレスフレームワークの上にステートフルなものを構築するのは比較的容易ですが、 その逆のステートフルなフレームワークをステートレスに見せるのは難易度が高いです. よってより自由度の高いステートレスを基本とし、ユーザが必要であればステートフルに仕上げることも出来るようにしました.

-コードを小さくシンプルに保つ

保守しやすく、何かあってもユーザが修正しやすいコードを維持します.

-フレームワークのフレームワークの位置を目指す

単体でよりもむしろラップして使われることを意識したつくりにします. T2フレームワークはそれ単体で使うときよりも何かとあわせて使うときに その威力を発揮できるようなつくりを目指します.

-極力美しいURL(RESTライク)を実現しやすくする.ただし強制はしない

URLの美しさ・見易さ・直感性はWebアプリケーションにとって非常に大事だと考えています. そのため、できるだけRESTライクなURLを使えるように機能を洗練させます. ブックマーカブルな綺麗なURLを使ったシステム開発がT2の目指すべき目標のひとつです. ただし、そのような綺麗なURLは強制ではなくあくまで実現方法の一つとして捉えています.

-保守を考えた足跡を残すような開発を可能にすること

システム開発を考えた場合に、保守のことを無視することは出来ません. 保守性、これがT2が重要視するキーワードの一つです. 保守を担当する開発者がT2で開発された実装成果物を引き継いだときに、 なるべく違和感なく、わかりやすいようなコードを開発できるようなフレームワークにしていきます.

具体的に目指すものとしては以下のようになります.

  • 目に見えないものより見えるものを優先する.例えば規約よりもアノテーションを使う
  • 侵略的でない方法で制約をあたえ、出来るだけ枠組みの中で開発できる
  • フレームワーク自体の互換性を保ち、長いスパンで同一フレームワークを動かすことが出来る

-プラグインによる拡張機能の枠組みを提供する

Webフレームワークは、そのユーザごと・業務ごと・開発するチームごとによって必要な機能は千差万別です. そのため、フレームワークとしてある程度の拡張性を維持するためにT2にプラグインを差し込める枠組みを準備します.

-マルチビューフレームワーク

T2では使うビューテクノロジを自由に選ぶことが出来ます. 例えば、JSPでの開発でも使えますし、FlexやAIR、SilverlightなどのRIA(Rich Internet Application)開発でも 利用できます.このようにビューテクノロジの種別を問わないで開発可能なのがT2です.

T2がやらないこと (Things T2 does not do.)

-バリデーション

バリデーションはユーザの方が適切に選択して、Pageクラスのメソッド内に記述する必要があります. バリデーションはフレームワーク側で勝手にやるべきことではなく、ユーザが最も手になじむバリデーションの 仕組みを使って適切に行うべきと私達は考えます(ただし今後の予定として、バリデーションのユーティリティ程度は 準備するかもしれません).

例えばOvalフレームワークやCommons Validator、または自作のバリデーションユーティリティなどが 良い選択ではないでしょうか.

-フレームワークによる自動コンバージョン

これは全ての場合ではないですが、原則としてT2ではフレームワーク内部による 自動コンバージョンは行いません.ただしそれを徹底してしまうとあまりに使い勝手が悪くなるので、 適切なバランスを絶えず見つけるようにしていきます.

-リッチコンポーネントの開発

実際にどのようなViewが使われるのかをT2ではあまり意識していません. Viewのコンポーネントは各プロジェクトによってその特性は異なります. そのため、私達T2プロジェクトではなるべくViewコンポーネント自体はもたないようにしています.

TOPに戻る

Powered by Google Project Hosting