Responder Module：フレームワークを分割して考える

作ってきたTuum/Respondが何なのか、良い説明を思いついたので書いてみます。

フレームワークの機能

最初に、フレームワークの機能を次のように分割してみます。

1. ブートストラップとアプリ構築。
2. ルーティングとディスパッチ。
3. モデル/ドメイン実行。
4. ビューなどのリスポンス構成。

この中で、最も重要と思うのが(3)のドメイン部分。これこそがプロジェクトの本質で、一番時間を使って開発したい部分。

フルスタック・フレームワークとは、(3)以外のほぼすべての機能を使いやすい形にまとめあげておくことで、ドメインの開発に集中するためのものだと考えてます。

一方、俗にいう「マイクロフレームワーク」というのがあります。これは、(1)と(2)の部分を担っていると考えるとスッキリします。返信するのが簡単なJSONであれば、複雑なビューなどを省くことで、コードが簡潔になります。

Responder Module

こんなふうに分割してみると、この(4)だけをターゲットにしたミニフレームワークみたいなものがあってもいいのでは？

と考えて、この(4)の機能の部分を作ってみたのが「Tuum/Respond」というモジュールです。

ついでに、この部分に「Responder Module」と名前をつけてみました。もう名前があるのかもしれないけれど、見つからなかったので、適当に呼んだだけです。

Tuum/Respond

Tuum/Respondの使い方としては、例えばSlim frameworkのようなマイクロフレームワークと一緒に使うとかを想定してます。

レスポンスの種類

想定しているレスポンスの種類です。

• View：HTMLなどのコンテンツのあるレスポンス。
• Redirect：別URIへのリダイレクト。
• Error：エラー。コンテンツがある場合もある。

それぞれHTTPステータスの200番台、300番台、そして400と500番台に対応します。

どのレスポンスを返す場合でも同じAPIが使えます。更には、リダイレクトした次のビューにデータを渡す場合でも、同じAPIになります。つまり、こんなコード。

$app = new App(); // some micro-framework app. 

// redirects to /jumped.
$app->get('/jumper', function($request, $response) {
    return Respond::redirect($request, $response)
        ->withMessage('bad input!') // <- set up info.
        ->withInputData(['some' => 'value'])
        ->withInputErrors(['some' => 'bad value'])
        ->toPath('/jumped');
    });

// ...and this is jumped.
$app->get('/jumped', function($request, $response) {
    return Respond::view($request, $response)
        ->asView('template'); // with the 'welcome!' message.
});

どこかで見たコードですね。

必要なサービスとインターフェース

Tuum/Respondの全ての機能を使うには、外部サービスが必要です。全てのサービスにはインターフェースが定義されています。

• ViewStreamInterface：
  ビュー（テンプレート展開）用API。PSR7のStreamInterfaceを継承していて、内部でテンプレートを展開。
• SessionStorageInterface：
  セッションおよびフラッシュ用API。ほぼAura.Sessionのsegmentと一致してます。
• ErrorViewInterface：
  エラー表示用API。

これらのサービスを実装して適宜設定することになります。

もう少し細かい説明は前にブログに書いてあるので、そちらも参考にしてみてください。