タグ別アーカイブ: Symfony

マイクロフレームワークっぽく使う Symfony 4 事始め 1 ~インストール編~

PHPのWebアプリケーションフレームワーク Symfony 4.x をマイクロフレームワークっぽく利用し始める事始め(入門)をまとめてみたいと思います。Symfonyは公式のドキュメントがそれなりに充実しているのでそこを読める人であれば読めばOK!なんですが、あまりにも日本語の情報が無く、有ってもバージョンが古い頃の情報だったりしてちょっとつらいです。今回は以下の環境でまとめています。私自身が使い始めたばかりなのでよく分かっていない部分はよく分かっていないと書いています。

Symfony: 4.2
PHP: 7.2 (Windows版ですが他の環境と特に違いは無いです)
Composer: 導入済み
MySQL: 8.0 (Windows版ですが他の環境と特に違いは無いです)

PHPのビルトインサーバーで動作するのでApacheやNginxは開発環境で動かす分には不要です。

インストール

インストール完了までの手順は以下の記事を大いに参考にさせて頂いております。リンク先の方が詳しいです。

Symfony4をインストールして”Hello World”を表示させるまでの手順 | QUARTETCOM TECH BLOG
Installing & Setting up the Symfony Framework (Symfony Docs)

プロジェクトを作るディレクトリに移動しComposerでインストールしていきます。symfony/skeltonを導入する事で必要な最小限の諸々 + Symfonyのパッケージ管理を楽にするための仕組み Symfony Flex が導入されます。

composer create-project symfony/skeleton <プロジェクト名>

作成されたプロジェクトのディレクトリに移動し、PHPのビルトインサーバを使うための Server レシピを導入します。serverという名前指定だけで目的のパッケージが導入されますが、この部分がFlexにより支援されている部分のようです。

composer require server

導入後は以下のコマンドでビルトインサーバーが起動します。consoleファイルの中身はPHPで実行するようにshebangが設定されたPHPファイルです。Windowsの場合はコマンドの頭に「php 」を付けてPHPのファイルである事を明示的に指定してやれば同様に動きます。

php console/bin server:run

実行した様子。Ctrl+C で終了。

コントローラなどを生成できる maker レシピ、コントローラを実装する際に定義ファイルの編集ではなくコントローラコード上のアノテーションで行えるようにする annot レシピを導入します。アノテーションでルーティングする機能は実態としては sensio/framework-extra-bundle に含まれています。デバッグ・プロファイリングに便利な debug-pack も導入します。

composer require maker
composer require annot
composer require debug-pack

テンプレートエンジンにTwigを使いたいので twig レシピを導入します。APIサーバーとして使う(JSONしか返さないつもり)なら入れなくても良いんじゃないかと思います。

composer require twig

これで「何かしらのURLにアクセスしたらコントローラがルーティングしてテンプレートエンジンがテンプレートを使ってページを表示する」という基本部分が完成しました(DB処理は後からふれます)。

色々と導入してきましたが、それに伴いconsoleコマンドでCLI実行できる機能も増えています。 bin/console xxx:xxx で使えるコマンドの一覧は特に引数を渡さずに実行すると確認できます。

php bin/console

以下が実行結果。多いので中略しています。

Hello World

決まった文字が文字が表示されるだけのページを作ってみます。以下のコマンドでコントローラを作成します。

php bin/console make:controller RootController

テンプレートとコントローラが作成されました。 maker:controller は便利コマンド的な物なので作り込んで来たら既存のコントローラをコピペするなどして手動で作成しても良いのですが、最初はこれを叩いた方が簡単です。

この時点でのプロジェクトのルート配下のファイル・ディレクトリ構成は以下のような感じになっています。

  • /bin :consoleコマンドやあとで導入するphpunitコマンドがここに入ります。
  • /config :各種設定ファイルが入ります。
  • /public :ドキュメントルートはここ。index.phpの場所。
  • /src :PHPのコード
    • Controller :コントローラーが作られる場所。
  • /template :Twigテンプレートの場所。src配下ではない。
  • /var :ログファイルであったりなどがここに作られます。
  • /vendor :Composerで導入されていくパッケージ。
  • .env :これもSymfonyの環境設定に関わるファイル。ここで環境によって設定を変えたりできる?
  • composer.json :Composerで導入されたパッケージの管理。
  • composer.lock :同上。
  • symfony.lock :Symfony関連のパッケージ管理。謎が多い。

コントローラのコードは以下のようになっています。

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;

class RootController extends AbstractController
{
    /**
     * @Route("/root", name="root")
     */
    public function index()
    {
        return $this->render('root/index.html.twig', [
            'controller_name' => 'RootController',
        ]);
    }
}

PHPDocに記載の有る @Route 定義がアノテーションによるルーティングです。”/root”にマッチするURLが来た場合にこの index 関数が実行されます。nameはユニーク(他とかぶりが無い)である必要が有るので注意してください。

結果はResponseオブジェクト( Symfony\Bundle\FrameworkBundle\Controller\Response)をreturnで返します。$this->render() を呼び出すとTwigでレンダリングした結果をResponseオブジェクトとして返してくれます。JSONで返したい場合は $this->json() という関数が有ります。

Twigテンプレートは以下のようになっています。

普通のTwigテンプレートなので特に必要はないかと思いますが、念のため雑に説明しておきます。

  • {{ xxx }} 変数の表示。自動でHTMLスケープされます。
  • {% xxx %} 変数を表示する以外の分岐やループなどの機能は {% で囲まれます。
  • {# xxx #} コメントアウト。コメントアウトは {# で囲みます。

$this->render() 時に渡した変数 controller_name からコントローラー名「RootController」が表示されるようになっていますね。

ではページを見てみます。php bin/console server:run でビルトインサーバを起動し、Webブラウザで http://127.0.0.1:8000 にアクセスします。

これはデフォルトのルートページ的な物になり、画面左下にも出ているように HTTP 404 Not Foundとなっています。ページ下部に表示されているステータスコード、処理時間、エラーログ確認などが debug-pack で導入された機能によって表示されているプロファイラ機能です。クリックするとより詳細な情報を確認する事が出来ます。

作成したコントローラに対応する http://127.0.0.1/root にアクセスしてみます。

目的のページが表示されました。画面左下よりステータスコードも HTTP 200 (正常) となっていますね。

とりあえずここまででページを表示するための最低限のものが動くようになりましたが、ルーティングの詳細やDB処理などまだ必要な物が有ります。次はルーティングについてまとめます。

ここまでのコードの状態は以下を参照してください。
https://github.com/lf-uraku-yuki/symfony4_tutorial/tree/tutorial01

続きの記事


WSL (Windows Susystem for Linux) を本格的に開発で使い始めた話

とある理由から WSL (Windows Susystem for Linux) を本格的に開発で使い始めました。その環境や手順、所感など。

前提: これまでの開発環境

  • PHP (Windows版)、メインで使うバージョンだけパスを通し、それ以外のバージョンは手打ちという方法で簡単に複数バージョン共存できます。WebサーバーもPHPのビルトインサーバを使います。
  • Composer(Windows版)、こちらもWindows版が有りあります。
  • MySQL (Windows版)、MySQL / MariaDB を使っている環境の開発用。唯一Linux向けと明確に異なる点としてDB名やテーブル名の大文字小文字を区別しませんが、小文字しか使わないので特に問題になりません。
  • PostgreSQL(Windows版)、PostgreSQLを使っている環境の開発用。特に何も困らず動きます。
  • Node.js、Windows版を利用。Node.js向けのアプリを書くのではなく各種ツールを利用するために導入。npmやwebpackなど特に問題なく動きます。
  • Redis(Windows版)、Windows向けのRedisは若干バージョンが古いものしか見つかりませんがまぁ普通に動きます。
  • Git for Windows、どちらかというとmingwを利用するための導入。実際のGitクライアントとしてはSource TreeのWindows版を利用しています。

前提: これまでのノウハウなど

Windows環境にちゃんと動くComposerを導入する

Windows環境のComposerを複数PHPバージョンで使い分ける

WindowsのコマンドプロンプトからOS標準のsshやtarやcurlコマンドを使う

上記を雑にまとめるとPHPの複数バージョン共存はWindowsでも簡単だし、ごく一部でLinux環境に依存しているComposerパッケージもGit Bashから実行すれば問題無いという話です。

発生した課題

この環境で長らく問題が無かったのですが、Symfony 4 + Flex の環境で開発するにあたって、/bin/console からのコマンドがコマンドプロンプトからは上手く動作しません。これは consoleがWin32なバイナリではなくshebang でPHPを実行しているからなので、ちょっと工夫すれば動くかと思われるのですが、せっかくLinuxに依存する物の実行環境としてgit bashを用意しているのでそれを使ってみます。

実際git bashで問題なく動くのですが、git bash(の利用しているmingw)の限界としてCtrl + Cでビルトインサーバーを止める事が出来ませんでした。どちらも制限アリで使えるのですが、この際せっかくなので本格的なLinux環境としてWSL (Windows Subsystem for Linux)を導入してみます。

WSLはかつてのバージョンではソケット通信が出来なかったりPostgreSQLなどの高度なツールが使う一部の機能に対応せず動作しなかったりデーモンとしてのプログラム起動が出来なかったりしましたが、2018年10月13日現在のWindows 10 リリース1803においては問題ない状態となっているようです。

導入方法

ググればいくらでも情報は出てくるので簡単に。ただしWSLリリース初期は今とは若干異なる手順でしたので古い情報にはお気を付けください。

  1. 「プログラムと機能」→「Windowsの機能の有効かと無効化」→「Windows Subsystem for Linux」を有効化。OS再起動を求められるので再起動します。

  2. Microsoft StoreでUbuntu 18.04 LTSをインストール。他のバージョンやUbuntu以外にもいくつかディストリビューションが選べます。
  3. スタートメニューからUbuntuを起動する。初回起動はインストールの続きが行われるので長めです。一般ユーザー名とsudo時に使うパスワードを求められますがどちらもWindowsのログインに使っているものと同じでにしました。
  4. フォント指定やデフォルトウィンドウサイズの変更はタイトルバー右クリック→「プロパティ」から。個人的にターミナル向けフォントとして長年使っているVLゴシックを指定。
  5. インストールしたままだと一部パッケージが最新でないのでaptコマンドで初回のパッケージ更新を行います。
    sudo apt update
    sudo apt upgrade
  6. あとはほぼ普通のUbuntu Linux環境ですのでaptコマンドなりなんなりで必要なツールチェーンを入れます。私はUbuntu公式のレポジトリからPHP 7.2を導入しました。Windows上のドライブは /mnt/ 配下にマウントされているので開発中リソースはそのままWSL上からも見えますのでどちらからも編集できます。

動作状況

Symfony 4 + Flex の /bin/console CLIなど特に問題なく動作します。/bin/console server:run によるビルトインサーバ起動も問題なく動き、Ctrl + C による終了も問題ありません。

今回PHPを実行する環境としてWSL上でPHPを動かしていますが、DBへの接続はlocalhost指定であろうとTCP/IP接続なので、これまで使っていたWindows版のMySQLやPostgreSQLに普通に接続できます。今はWSL上でもPostgreSQLなどが動きますが速度的にもとりあえずWindows版のまま使おうと思います。

また、ソースをWindows上で動くPHP Stormで編集する事も、それらをWindows版のSource TreeでGit管理する事も特に問題有りません。必要な部分だけをWSL上から実行する事が出来ます。

速度は気持ち程度遅いですが、PHPビルトインサーバを使っている分には特に困らないです。

所感

以前は辛い部分も多かったようですが、今の所思っていた以上に普通のLinux環境として使えます。普段からLinuxサーバーを触っている身としては独自の文化やしきたりを求められないのは使いやすいです。各種アプリパッケージの導入も apt コマンドなど「Linuxディストリビューションとして普通の方法」で行う事が出来ます。Virtual Machineのような環境ではなく、あくまでWindowsのまま必要なツールだけをWSL上から実行できるのも使い勝手が良いですね。

動作速度的にもWSL上でRDBを起動し巨大なテーブルを幾つも載せる、といったような使い方にはあまり向いていないと思われるので、RDBはWindows版を使ったまま「これまで以上にリッチかつナチュラルに使えるLinuxツールチェーン環境」として使うのが良いんじゃないかと思います。