Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

Slimの最新バージョンリリース、アップグレードの方法を解説

軽量PHPフレームワークSlimを習得しよう 第7回

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/01/23 11:00

 本連載では軽量PHPフレームワークであるSlimを紹介していきます。フレームワークといえば、重厚長大なもの、いわゆるフルスタックフレームワークが多い中で、あえて軽量フレームワークを取り上げます。軽量ゆえのメリットを味わっていただこうと思います。前回は、リクエスト処理を1つのクラスにまとめる方法としてコントローラクラスを紹介しました。今回は、当初の予定を変更して、リリースされた最新バージョンのSlimバージョン4とTwig-Viewバージョン3にアップグレードする方法を紹介します。

目次

Slimバージョン4リリース

 前回のコントローラクラスを紹介する原稿を書き上げたのちの2019年8月1日にSlimのメジャーアップデートであるバージョン4がリリースされました。その後、マイナーバージョンアップを重ねて、この原稿執筆時点では4.4がリリースされています。

メジャーアップデートは破壊的変更

 Slimは、そのバージョニングのルールとして、セマンティックバージョニングを採用しています。セマンティックバージョニングでは、最初の数字が大きくなる時、つまりメジャーアップデートが行われる際、下方互換性のない破壊的変更が行われていることになります。

 そのv4で行われた主な変更は次の通りになります。

  1. 必須PHPバージョンが7.1以上になった。
  2. Appクラスはnewせずにファクトリクラスからもらうようになった。
  3. ルーティングパターンが相対パスではなく絶対パスになった。
  4. リクエストとレスポンスオブジェクトがPSR-7に準拠するようになった。
  5. DIコンテナを内包しなくなった。
  6. ルーティング処理やエラーハンドラをミドルウェアとして実装するようになった。

 この連載において、上記のうち、1はもともと最新のXAMPPを利用しているので問題ありません。6はまだ紹介していない内容なので、今後の回ではv4の内容で紹介します。

 問題となるのは、2~5です。これらの変更のために、この連載中で紹介してきたサンプルは、現状の最新環境では動作しません。今回は、それらを動作させるように改造する方法を紹介しながら、上記変更点の2~5の内容を中心に紹介して、アップグレードの方法としたいと思います。

 その際、上記2~5以外の細かい変更も紹介していきます。

Twig-Viewもメジャーアップデート

 Slim v4に合わせてTwig-Viewもメジャーアップデートが行われ、2019年12月18日にバージョン3がリリースされています。このリリースでは、Twig本体のメジャーアップデートであるバージョン3への対応も含まれています。こちらの使い方も次節以降紹介していきます。

依存パッケージのアップデート

 これまで紹介してきたサンプルを最新環境で動かすためには、Composerの依存パッケージを最新にしておく必要があります。

 composerには、依存パッケージのアップデートを行うupdateコマンドがありますが、これは、あくまでcomposer.jsonファイル内で指定された範囲でのアップデートであり、メジャーアップデートへのアップデートは原則行われません。

 そういった場合、もう一度requireコマンドを実行すれば最新のバージョンに対応できます。これまで利用してきた次のパッケージに対してrequireコマンドをもう一度実行してください。

  • slim/slim
  • slim/twig-view
  • monolog/monolog

 さらに、上述の変更点4にあるように、Slim v3では内包していたリクエストとレスポンスのクラスを、v4では切り離すことにしました。v4では、PSR-7に完全準拠させたために、PSR-7を実装したクラス群を別パッケージとするようになりました。そこで次のパッケージもrequireして、パッケージを配置しておいてください。

  • slim/psr7

/helloを表示させるには

 連載第2回で作成した/helloは、そのままではv4では動作しません。それをまともに表示させるところから始めましょう。

Appインスタンスはファクトリからもらう

 まず、上記変更点2への対応です。これは、index.phpの改変となります。現状次のように記述されていると思います。

<?php
use Slim\App as App;  // (1)
〜省略〜
require_once("../vendor/autoload.php");
$app = new App();  // (2)
〜省略〜
require_once("../routes.php");
〜省略〜
$app->run();

 この(1)と(2)の部分を次のように書き換え、(3)を追記します。

[リスト1]firstslim/src/public/index.php
<?php
use Slim\Factory\AppFactory;  // (1)
〜省略〜
require_once("../vendor/autoload.php");
$app = AppFactory::create();  // (2)
〜省略〜
$app->setBasePath("/firstslim/src/public");  // (3)
require_once("../routes.php");
〜省略〜
$app->run();

 v3ではAppクラスをnewしていましたが、v4ではAppFactoryのstaticメソッドであるcreate()を実行してAppインスタンスをもらうように変更になりました。そのための変更がリスト1の(1)と(2)です。

ベースパスの設定が必要になった

 次に、リスト1の(3)の追記についてです。これは、変更点3への対応です。

 ルーティングパターンは、第2回の「Slimの動作原理」で解説したように、v3までは「index.phpが実行されるポイントからの相対パスで記述」していました。これが、v4からは、絶対パスとなります。ということは、

  • http://localhost/firstslim/src/public/hello

 で動作させたいリクエスト処理のルーティングパターンは

  • /firstslim/src/public/hello

 で登録する必要があります。ところが、このうち、「/firstslim/src/public/」の部分はこのアプリ共通のパス、つまり、ベースパスといえます。このベースパスを含めていちいちルーティングパターンに記述するのは無駄です。そこで、ベースパスを登録するメソッドがAppクラスにはあるので、これを利用します。それがsetBasePath()であり、そのメソッドを実行しているのがリスト1の(3)です。

 これで、index.phpへの変更は終わりです。

リクエスト処理の戻り値がResponseに統一

 次に、リクエスト処理に移りましょう。/helloを表示させるリクエスト処理は、現状、src/routes.phpファイルに記述されている次のコードです。

$app->get("/hello",
	function(Request $request, Response $response, array $args): void {
		print("<h1>Hello World!</h1>");
	}
);

 リクエスト処理本体であるコールバック関数に関して、現状戻り値がありません。第2回の「Slimの動作原理」で解説したように、v3まではリクエスト処理であるコールバック関数やコントローラメソッドの戻り値は、無し(void)か、Responseオブジェクトのどちらかを選べました。

 これが、v4からはResponseオブジェクトを必ずリターンする仕様に変わりました。したがって、上記コードはリスト2のように変更する必要があります。

[リスト2]firstslim/src/routes.php
<?php
〜省略〜
$app->get("/hello",
	function(Request $request, Response $response, array $args): Response {  // (1)
		print("<h1>Hello World!</h1>");
		return $response;  // (2)
	}
);

 変更点は、(1)の戻り値の型の記述と、それに伴う(2)のreturn文の記述です。なお、リスト2のように、v3では戻り値を記述する必要がなかったコールバック関数、あるいはコントローラメソッドの場合、それらコールバック関数やメソッド内で特にレスポンスオブジェクトに対して処理を行っていません。その場合は、第2引数の$responseをそのままリターンすればいいでしょう。

 これで、/helloは問題なく動作するようになります。

 さらに、第3回で紹介しているリスト1~6は、コールバック関数内にリスト2の(1)のように戻り値の型をResponseとし、(2)のreturn文を記述することで、問題なく動作するようになります。

ルーティンググループ登録の引数の型が変更

 ルーティンググループの登録方法も少し変更になっています。第3回の「ルーティンググループ」でルーティンググループ登録として次のコードを提示しました。

$app->group("/members", function(App $app): void {
	$app->any("/showList", …);
	$app->any("/entry", …);
	$app->any("/showDetail", …);
});

 このgroup()メソッドの第2引数のコールバック関数の引数の型が、v3ではAppとなっています。これが、v4では変更になっており、\Slim\Routing\RouteCollectorProxyとなっています。したがって、ルーティンググループの登録コードは次のようになります。

$app->group("/members", function(RouteCollectorProxy $group): void {
	$group->any("/showList", …);
	$group->any("/entry", …);
	$group->any("/showDetail", …);
});

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • WINGSプロジェクト 齊藤 新三(サイトウ シンゾウ)

    <WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きた...

  • 山田 祥寛(ヤマダ ヨシヒロ)

    静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XMLD...

バックナンバー

連載:軽量PHPフレームワークSlimを習得しよう
All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5