2016年1月16日土曜日

Qiita：PSR-7のミドルウェアは、何故ああなのか？」

Qiitaに投稿しました。


PSR-7でよく見るミドルウェアの引数（シグネチャ）に関する話です。どうして、あの形が使われるのか考えてみました。

なんというか、LTネタ的な話です。
2 件のコメント:

2016年1月7日木曜日

2015年を振り返って２（Tuum/Respond開発日誌メモ）

２０１５年を振り返って、の続きです。

昨年の2015年6月から始めたのが「Tuum/Respond」というプロジェクト。開発方針を転換して、PSR-7ベースのマイクロフレームワークに後付でViewの機能を追加するパッケージを目指しました。

面白かったのは、開発してゆくにつれ、どんどんコードが簡単になってゆきました。機能を絞ったことで、何をしているか理解できたからと思います。

いったい何をするのか。
自分で理解した形で説明します。
使い方とかは、Githubのページを見てください。

要するに次の2つを管理するパッケージです。

  • ViewData: ビューを作るのに必要な情報を運ぶデータ転送オブジェクト。これに必要な情報を設定してゆく。
  • ViewInterface: ViewDataからテンプレートなどでビューを構築して、レスポンスを返すインターフェース。

これだけなのですね。

ViewerInterface


Tuum/Respondの肝は、様々な方法でレスポンスオブジェクトを構築すること。

レスポンスを構築する、ということは、ビューを構築する、とほぼ同じです。ということで、次のインターフェースが出来ました。

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Tuum\Respond\Responder\ViewData;
interface PresenterInterface {
    /**
     * renders $view and returns a new $response.
     *
     * @param ServerRequestInterface $request
     * @param ResponseInterface      $response
     * @param ViewData               $view
     * @return ResponseInterface
     */
    public function render(
ServerRequestInterface $request,
ResponseInterface $response,
$view);
}

リクエストとレスポンスのオブジェクト、それとビュー構築に必要なデータの入ったViewDataというオブジェクトを受け取ります。適宜ボディを構築して、レスポンスオブジェクトを返します。

ついでに同じインターフェースで、ちょっと動きの違うAPIを定義しました。

interface ErrorViewInterface extends PresenterInterface {}
interface ViewerInterface extends PresenterInterface {}

この３つのインターフェースの使い分けは、


  • PresenterInterface:
    $viewを受け取って、レスポンスを返す汎用インターフェース。
  • ViewerInterface:
    テンプレートからビューを描画することで、レスポンスを返す。
  • ErrorViewInterface:
    ステータスコードに対応するテンプレートを描画することで、レスポンスを返す。エラー用。


それぞれのインターフェースを実装したクラスを作っておいて、呼び出します。次のコードを見ると、どれがどのAPIに対応するか、すぐわかると思います。

Response::view($req)->view('template/filename');
Response::error($req)->forbidden();
Response::present($req)->call(MyPresenter::class);


ViewData


もう一つの肝が、ViewDataというデータ転送オブジェクト（DTO）。Tuum/Respondとは、要するにViewDataを設定しつつ持ちまわるためのライブラリです。そして、最後にPresenterInterfaceのオブジェクトを呼び出します。

このコードだと、$viewを直接いじってからテンプレートを描画します。

Respond::view($req)
  ->withViewData(function($view) use($value) {
    return $view->setData('key', $value);
  })->view('my/template');

あるいはRedirectでは、ViewDataをSessionのフラッシュに保存します。

Respond::redirect($req)
  ->withMessage('hello')
  ->to('/my/path');

次のリクエストで、フラッシュからViewDataを読み込むことで、データを簡単に利用することが出来ます。


インターフェース遷移


想定しているマイクロフレームワークとTuum/Respondについて、インターフェースという切り口で考えて見たら面白かったので、書いてみます。

最初に、リクエストとレスポンスから**ミドルウェア**が始まります。`$next`が次のミドルウェアですね。

middleware($req, $res, closure $next);

ミドルウェアの最後にルーターが走り、実行する**コントローラー**を呼び出します。`$args`がルートパターンでの変数です。此処から先が、ユーザーコードに入ってゆく感じです。

controller($req, $res, array $args);

コントローラーでは、ドメインを操作したり、必要なビューを構築してレスポンスを返します。

ビューの構築を手助けするのが、`Tuum/Respond`で、次のようなインターフェースになります。

viewer($req, $res, ViewData $view);

$viewに情報を設定する、テンプレートを描画する、レスポンスを構築する、など様々な処理を行えます。

なんかMiddleware-View-Controller (MVC)みたい。

開発は楽しい


開発していると、動くところまで作るのは楽しいとよく言われます。

その後でも、リファクタリングしたり作りこむのも、理解が深まったり新しい見方が出てきたりして別の楽しさがあります。自分の趣味のパッケージでないと中々出来ないので、これからも続けてゆきたいです。

0 件のコメント:
話題：

2015年を振り返って（Tuum開発日誌メモ）

2016年になったので、自分用のメモとして去年のTuumPHP開発を振り返ってみます。

Tuum/Webの開発


思えば、Tuum/Webを作り始めたのは2014年の11月頃。一度ぐらい満足できるフレームワークを自作してみたい、と思い立ってしまい、

  • 良いとされる設計を積極的に使う（PSR-7、ミドルウェア、DIコンテナなど）、
  • そのうえで、自分の欲しい機能を実装する、

という方向で作り始めました。

2015年5月頃には、ほぼ完成したのですが、どうも気にかかる点が出来てしまいました。おそらく、次の二点。

1. 思った以上に複雑になった。
2. 欲しいのはフレームワークではなかった。

なので、基本ボツに。

えぇ〜！
せっかく作ったのに。

複雑すぎる


一つ一つの設計は自分なりに納得して作ってるので、妙な動きはしてはいないのですが。思った以上に動きが複雑になってしまいました。原因を考えたのですが、次の２点になると思います。

  • 良いと思える設計から少しずれた、
  • 自分が欲しい機能について、理解してなかった、

一番最初にミドルウェアの引数をどうするか悩んだのですが、できるだけ簡単な形を選んでしまいました。使う分には簡単そうに見えるのですが、フレームワーク側が複雑になってしまいました。

自分が採用した形が、

$response = $middleware($request);

の形。
これだと、帰ってくる$responseに対して処理を行うことが出来ません。そのため、戻りループ用の別インターフェースを作って、としているうちにコードが「ちょっと」複雑に。ちなみに、Symfonyも似たようなことをしてるので、それほど悪い実装ではないはず。

一方、ほぼ標準になりつつある形が

$response = $middleware($request, $response, $next);

$nextとか面倒だなと思ってました。が、フレームワーク作ってみて、このAPIの良さがわかってきました。

もう一点は、次のTuum/Respondの開発をして分かりました。自分の欲しかった機能を十分に理解できてなかったからです。単体のパッケージを作ることで、機能についてじっくりと考えられたわけです。


欲しいのはフレームワークではない


で、この理由。

勉強のために作ったというのもあるので、そこそこ良いフレームワークができたら、もういいかなという気になった。と言うのはあります。

さらに、PSR-7ベースで、素晴らしいマイクロフレームワークがいくつも出てきてます。Slim3とかExpressive。それにRelayもミドルウェアディスパッチャーとしてよく出来てます。

結局、自分が欲しいのは、先に書いた「欲しい機能」の部分であり、フレームワークではありません。すでにあるマイクロフレームワークを利用して、自分の欲しい機能が追加できれば、十分なわけです。

コーディングの勉強には最適


とはいえ、フレームワークを自作するのは、コーディングの練習には最適ですね。やってよかったなと思ってます。

ということで、次の開発話に続きます。

0 件のコメント:
話題：

2015年7月6日月曜日

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。

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

もう少し細かい説明は前にブログに書いてあるので、そちらも参考にしてみてください。
0 件のコメント:
話題：

2015年7月1日水曜日

汎用ページネーション（PSR7も使えます）

汎用ページネーションのパッケージを作ってみた。
一応、PSR7のServerRequestInterfaceも使えます。

セッションを使って、ページ番号やフォーム入力を覚えるのが特徴。簡単に最後と同じページを作成できます。

何故作ったのか？


仕事でDoctrine2を採用してみたのだが、いい感じのページネーションがなかったので作ってみた。ただし仕事には間に合わなかったので、実サイトでの実績はないです。

こういうページネーションに、どのぐらい需要があるのかわからないけど、この際なのでパッケージとして作ってみた。

ライセンス：MIT
PSR準拠　：Psr-1、Psr-2、Psr-4

使い方


インストール


composerで。

$ composer require "wscore/pagination"


Pagerオブジェクト


Pagerオブジェクトを最初に作ります。

use WScore\Pagination\Inputs;
use WScore\Pagination\Pager;

// construction
$pager = new Pager(['_limit' => 15]);

// set up pager using Psr-7 ServerRequestInterface.
$pager = $pager->withRequest($request);
// or from global data. 
$pager = $pager->withQuery($_GET, '/find');

次に、データベースへのクエリなどを実行します。callメソッドにクロージャーを渡してください。引数はInputsというクラスのオブジェクトです。

$inputs = $pager->call(
    function(Inputs $inputs) use($pdo) {
        // query the PDO!
        $found = $pdo->prepare("SELECT * FROM tbl WHERE type=? and num>? OFFSET ? LIMIT ?")
            ->execute([
                $inputs->get('type'),
                $inputs->get('num'),
                $inputs->getOffset(),
                $inputs->getLimit(),
            ])
            ->fetchAll();
        $inputs->setList($found);
    });
$found = $inputs->getList();
$type  = $inputs->get('type');

後は、クロージャー内で必要な処理を書き込みます。
Inputsオブジェクトから、オフセットとリミットや、フォームの入力を読み取れます。

HTML出力


最後に、HTMLへの出力は、Paginateというオブジェクトを使います。

use WScore\Pagination\Html\Paginate;

$inputs->paginate(new Paginate());
echo $inputs->__toString();


すると、こんなページネーションが表示されます。


リクエストの仕方

ここが、このパッケージの肝になります。
「_page」を使いこなします。

１．検索条件フォーム


ページネーションを行う場合は、検索条件をフォームで選ぶ場合が多いと思います。その場合は、普通にフォームを作ってください。

<form>
<input type="text" name="type" />
<input type="integer" name="num" />
<input type="submit" />
</form>

注意：_pageは使わないで下さい。
フォームの内容は自動でセッションに登録されます。セッションは事前に走らせておいて下さい。

２．ページの指定


指定するページを表示するには_pageにページ番号を指定します。

GET /find?_page=2

検索に使う条件はセッションに保持されているので、同じ条件でオフセットを替えてクエリを実行できます。

３．最後の検索画面


検索画面を表示する際、_pageにページ番号をなしでGetしてみてください。

GET /find?_page

すると、セッションから最後のページ番号と検索条件を読みだします。

To Do


動くはずですが、実際に使ったことがないのでAPIなど変わるかもしれません。なのでアルファリリースです。

0 件のコメント:
話題：

2015年6月12日金曜日

PSR7用のヘルパーとレスポンダー

コツコツとフレームワークを作っていて。
ふと、自分が欲しかったのは、もっと簡単なことじゃないか？と思い直して作ったのが「Tuum/Http」というパッケージ。

【修正：2015/06/26】
「Tuum/Responder」に名前を変更しました。

そもそものスタートとして、SlimやStackPHPの簡潔な構造に憧れたところから始まっている。が、実際に使うとなると、API作るには便利だけれど、普通のウェブサイトを構築するには作業が面倒そうだなぁと。

面倒だと思った部分は、レスポンスを返す部分。たとえば前のページに戻ったり、ついでにメッセージやエラー情報を付加したりという部分。同じような処理が多い割には、細かな設定が必要な気がする。

そこで、この部分だけをパッケージにしてみた。


何をするパッケージなのか



大きくヘルパーとレスポンダーからできている。
大事なのはレスポンダーの方。

ヘルパー

Psr7に足りなさそうな機能をスタティックなメソッドとして提供している。見れば一発、簡単なものばかり。例えば、

$bool = ResponseHelper::isRedirect($response);

はリダイレクトレスポンスかどうかをチェックできる。RequestHelperとResponseHelperの２つがある。

レスポンダー

レスポンスを構築するためのヘルパー。
例えば、別パスにリダイレクトしたり、その際にメッセージを付加できる（単にセッション・フラッシュに登録してるだけだが）。

Redirect::forge($request, $response)->withMessage('welcome!')->toPath('jump/to');

// ...now in the subsequent request to a server...
Respond::forge($request, $response)->asView('template'); // with the 'welcome!' message.

次のリクエストの際に、前のメッセージが自動でビューに入ってくる。メソッド名がどこかで見たことのあるのは愛嬌。使いやすいと思ったので。

レスポンダーとしては、Respond、Redirect、そしてErrorがある。それぞれ、ビューを返す、リダイレクトを返す、エラーページを返す。

使うのに必要なこと：サービス


レスポンダーの機能を実現するために、ビューやセッションなどのサービスを使っている。これを作っておいて、レスポンダーに渡す必要がある。

セッション用インターフェース

セッションのフラッシュを使ってリクエスト間のデータを受け渡している。そのためのセッションとしてSessionStorageInterfaceという形で定義した。

と行っても、実際はAura.SessionのSegmentと同一のAPI。これを使うのが前提みたいになっている。

use Aura\Session\SessionFactory;

$factory = new SessionFactory();
$session = $factory->newInstance($_COOKIES);
$segment = $session->getSegment('some-name');

ここで作った$segmentがSessionStorageInterfaceと同じオブジェクトになる。

これを$requestに設定する。
use Tuum\Http\RequestHelper;
$request = RequestHelper::withSessionMgr($request, $segment);

あるいは、後で書くようにコンテナに設定しておく方法もある。

ビュー用インターフェース

HTMLを返すにはテンプレートを使ったビューを使いたい。そのために、ビューを展開するViewStreamInterfaceを定義してみた。

テンプレートを展開できるStreamとして扱う。

ViewDataクラス

これは実際のクラス。
ビューやリクエスト間でデータをやりとりするためのデータ転送用オブジェクト。

ビュー用のクラスはViewDataを理解して、実際のレンダラーに渡す必要がある。


コンテナー用インターフェース

サービスを管理するコンテナ。Container-Interopで定義したインターフェースを使った。これに必要なサービスを登録しておいて、$requestに設定する。

次はセッションを設定する方法。

$app = new Container(); // must implement ContainerInterface
$app->set->(SessionStorageInterface::class, $segment);RequestHelper::withApp($request, $app);




0 件のコメント:
話題：

2015年5月24日日曜日

PHPの__invokeメソッドの使いドコロは？

PHPにはクロージャー（無名関数）と、クラスを無名関数のように使えるようになるマジックメソッド、__invoke、というのがある。これに関する雑感。

クロージャーと言うのは便利なもので、プログラムをデータとして扱える。

$hello = function($world) {
  return 'hello ' . $world;
};
便利なケースを思いつかなかったので、適当に書いたコード。


一方で、__invokeメソッドの使いドコロは何だろう。

自分が思いつくのは、
１．流行りのファンクショナルな言語のように書ける。
２．メソッド名を考えなくても使える。
３．クロージャーの代わりにオブジェクトを使いたい場合に必要。

最初の１．と２．は冗談なので、実際は３．の場合かなと思える。つまり何かの関数の引数としてクロージャーを想定している場合でも、オブジェクトが使える。

でも３．の理由は、クラス自体でのメリットというより、必要だからという感じがする。

あとPHPの問題として、意外なところでコードのパースが悪いところがある。せっかくコンパクトに書けるはずのクロージャーなのに、かえってコードが複雑になってしまう。

class Hello {
  private $hello;
  function __construct($hello) {
    $this->hello = $hello;
  }
  function hello($world) {
    return $this->hello($world); // 動かない！
  }
}

なんで、こんなことを書いてるかって？

いや、１．と２．の理由で__invoke使って見たら、意外と面倒で。一方で感じたメリットは３．しかなかったので。それで__invokeメソッドを使うメリットは他に何があるか？そんなことを思ったのでブログに書いてみた。

0 件のコメント:
話題：
登録: 投稿 (Atom)