"BOKU"のITな日常

還暦越えの文系システムエンジニアの”BOKU”は新しいことが大好きです。

はじめてLaravel6.0:Bladeの基本・ロケール・多言語対応/Windows10

Bladeテンプレート構文の基本的な使い方・ロケール設定・項目名やメッセージなどの日本語化あたりを整理していきます。

題材に、Laravel6.0のコマンドで生成した認証機能の各画面のソースを使います。 

f:id:arakan_no_boku:20191003220222p:plain

 

はじめに

 

機能を動かしながらソースを読みこんでいくのが、Laravel6.0フレームワークの基本を理解する手っ取り速い方法です。

前回生成した「認証機能」は格好のサンプルなので、このソースを見ていきます。

arakan-pgm-ai.hatenablog.com

今回は特に以下に重点をおいてみていきます。

  • Bladeテンプレートの記述方法
  • バリデーションの方法
  • 言語化の方法

 それで、最終的に英語メッセージを日本語化したり、共通テンプレートの背景色とかをちょっと変更してみるとか、やってみます。

 

まずはユーザインタフェース部分

 

Bladeテンプレートを使っています。

その記述のポイントを見ていきます。

 

共通レイアウトテンプレートの継承

 

bladeテンプレートは拡張子「.blade.php」のファイルです。

まずは、「resources\views\auth」の下にある「.blade.php」ファイルを見ていきます。

実際のソースを見ると、resources\views\authフォルダの下の各ソースコードは、同じ構造になってます。

つまり。

@extends('layouts.app')

@section('content')

 ※ここにHTMLなどが書かれている

@endsection

みたいな感じでディレクティブに囲まれています。 

その最初の部分。

@extends('layouts.app')の「layouts.app」で、共通レイアウトである「views\layouts\app.blade.phpファイルを読み込んでます。

その「layouts\app.blade.php」ファイルを眺めてみると下の方に

<main class="py-4">

   @yield('content')

</main>

という部分があります。

なるほど・・「'content'」という名前で個別ファイルで定義された「@section~@endsection」の部分が、この@yieldの部分に挿入されるわけなんですね。

 

 

テンプレートにおけるデータ表示

 

続けて「resources\views\auth」の下にある「.blade.php」ファイルを見ていきます。

bladeテンプレートの構文は、こちらに詳しく書かれてますので、そこから関係あるところを拾い読み的にやっていきます。

readouble.com

まず、「{{  }}」で囲まれた記述です。

これは「 Bladeビューに渡されたデータを表示する記法」です。

セキュリティも考慮されてます。

引用すると。

デフォルトでブレードの{{ }}文はXSS攻撃を防ぐために、PHPhtmlspecialchars関数を自動的に通されます。

実にありがたいです。

もう少しよく見ていくと、認証機能の「.blade.php」ファイルには同じ{{}}構文でも、5通りくらいのパターンがありました。

  • {{ __('Login') }}
  • {{ $message }}
  • {{ old('remember') ? 'checked' : '' }}
  • {{ config('app.name', 'Laravel') }}
  • {{ asset('js/app.js') }}

 

一番目の書き方「{{ __('Login') }}」は多言語対応構文です。

'Login'に対応する日本語辞書を用意すれば、「ログイン」などと日本語表示できる書き方です。

 

二番目の「{{ $message }}」が一番シンプルな「変数の内容」を表示するものです。

 

三番目の書き方は、<inputタグの中とかで、バリデーションにはじかれた場合に、直前の入力の内容を復元するold関数を使った構文です。

 

四番目は「config」フォルダのファイルから値をとってくる構文です。

上記だと「config\app.php」内の「name」の値を表示し、なければ初期値の「Laravel」を表示する・・という意味です。

 

五番目の「asset」というのは、publicフォルダのパスを返します。

つまり、js(JavaScript)とか、cssとか、imagesとかの静的ファイルは、publicフォルダにサブフォルダをおき、その下にファイルを配置して、{{ asset('js/app.js') }}のように取得すれば良いというわけです。

 

テンプレートの@xxディレクティブ

 

今度は「@」ではじまる構文です。

例えば。

  • @if  -  @else - @endif
  • @error - @enderror
  • @csrf
  • @guest - @else - @endguest

です。 

これらは、Bladeの制御構文です。

@if  -  @else - @endif・・は、まあ見たらわかりますね。

@error - @enderrorは、これに囲まれている部分が「バリデーションエラーがあった場合」のみ実行されます。

@csrfは「隠しCSRFトークンフィールドを生成する」ディレクティブです。

これを置くと、CSRF保護ミドルウェアがリクエストを検査できるようになります。

@guest - @else - @endguestは、「ユーザが認証されていない」場合に囲まれている部分を実行します。

などなど、制御構文はたくさんあって、今回のソースコードに登場していないものなども、こちらのガイドの「制御構文」のところを見ればすべて書いてあります。

readouble.com

 

入力データのバリデーション

 

{{ $message }} でエラーメッセージを出力できることはわかった。

じゃあ、「$message」という変数はどこでセットされているのか?

答えはこちらに書いてありました。

関係しそうな部分を抜粋していきます。

readouble.com

コントローラクラスの中でルールを指定する方法で、バリデーションします。

そこで発生したエラーは、前にでてきたbladeテンプレートの「@error - @enderror」ディレクティブで拾うことができて、その内部で「$message」にセットされたエラーメッセージを表示できる・・と書いてあります。

つまり、$messageの内容は、Laravelのバリデーション機構で、暗黙的にセットされいると考えるとスッキリします。

 

バリデーションルールの指定方法

 

app\Http\Controllers\Authフォルダにコントローラクラスがあります。

いくつかファイルがありますが、例としてユーザ登録画面「RegisterController.php」を見てみます。

すると。

この中に画面の各項目に対応するバリデーションルールが設定されています。

 protected function validator(array $data)
    {
        return Validator::make($data, [
            'name' => ['required', 'string', 'max:255'],
            'email' => ['required', 'string', 'email', 'max:255', 'unique:users'],
            'password' => ['required', 'string', 'min:8', 'confirmed'],
        ]);
    }
    

こうやって、対応する項目にルールを紐づけるだけでいいんですね。

それだけで、そのルール名に紐づいたバリデーションロジックが動いて、エラーがあれば$messageにメッセージがセットされる。

実にスッキリしています。

指定可能なバリデーションルールも標準で沢山用意されていますし、今回はしませんけど、オリジナルバリデーションも作れます。

以下のページの最後の方に「指定可能なバリデーションルール」が書いてあります。

readouble.com

上記の「'password' => ['required', 'string', 'min:8', 'confirmed'],」のところを見ると。

  • required':必須入力チェック
  • 'string':文字列であるかチェック
  • 'min:8':8文字以上であるかチェック
  • 'confirmed:フィールドがそのフィールド名+_confirmationフィールドと同じ値であるかチェック

とあります。

confirmedとか、2つのフィールドの比較まで、ルールでできるのはスマートですね。

 

ロケールのデフォルトは英語圏のままなので変更しておく

 

artisanコマンドで生成しただけだと、英語で項目名もメッセージも表示されます。

ロケールはどうなっているのかな?

そう思い「config\app.php」を見ていると、やはり英語圏のままでした。

timezoneは「UTC」だし、localeは「en」だし・・。

とりあえず。

日本語表示とか日付・時刻処理に影響があるので、app.phpの該当箇所を以下のように変更しときます。

  • 'timezone' => 'Asia/Tokyo',
  • 'locale' => 'ja',
  • 'fallback_locale' => 'ja',
  • 'faker_locale' => 'ja_JP',

保存したら、configの変更を反映させるため以下のコマンドを実行します。

php artisan config:cache

これでロケールの変更が反映します。

 

日本語用の辞書を用意する 

 

ロケールを変更しただけだと、やっぱり表示は英語です。

そりゃあ、そうですね。

辞書がありません。

言語化対応のためには日本語の辞書が必要です。

言語化のやり方はこちらに書いてあります。

readouble.com

やり方はおおまかに2通りです。

 

{{ __('Login') }}構文で表示する翻訳ファイル

 

{{ __('Login') }}等の翻訳文字列をキーとする翻訳ファイルは、resources/langフォルダ下にJSONファイルとして保存します。

ファイル名はロケールに対応した名前です。

今回は「'locale' => 'ja',」と設定しているので、ファイル名は「ja.json」です。

つまり、「resources/lang/ja.json」ファイルに翻訳文を書きます。

 

バリデーションのエラーメッセージ等の翻訳ファイル

 

初期状態だと、「resources\lang\」フォルダに「en」フォルダがあります。

その下にあるphpファイルの中に、キーとメッセージが定義されてます。

例えば、こんな感じです。

'required' => 'The :attribute field is required.',

つまり。

これを日本語辞書とするには・・。

'required' => 'これは必須入力です。',

みたいに、キーに対応する日本語を書いたファイルを作ればいいわけです。

そして、その置き場所はロケールに対応した「ja」フォルダにします。

一から作るのは大変なので、 「resources\lang\en」フォルダ毎ファイルをコピーして、フォルダ名を「ja」にリネームします。

そして、以下の各ファイルの右側のメッセージ部分を日本語に翻訳すれば良いのですが、翻訳は手間です。

でも、ありがたいことに。

日本語化したファイルを既に作ってくださっている方がいました。

github.com

今回は、有難く使わせていただきます。m(__)m。

上記サイトから、ファイルをダウンロードして解凍し、「resources\lang」にコピーさせてもらうことにします。

 

最後にちょっとだけ背景色の変更

 

ここまでで確認は終わって、ちょっとおまけで背景色変更をしてみます。

背景色が白一色というのが、どうも見づらいので、共通ヘダーだけでは色をつけておきたいと思ったからです。

 「resources\views\layouts」フォルダの「app.blade.php」(共通レイアウト)の24行目あたりの<navbar>を以下のようにします。

<nav class="navbar navbar-expand-md navbar-dark bg-primary shadow-sm">

 navbar-lightの代わりに「navbar-dark bg-primary」を設定しただけですけどね。

 

さて実行してみます

 

今回、ここまで変更したことが、正しく反映するかを実行して確認します。

実行には、ビルトインサーバーを使います。

php artisan serve

http://localhost:8000/register にアクセスすると。

f:id:arakan_no_boku:20191006144321p:plain

 

日本語化とヘダーの背景色変更はできてます。

エラーメッセージはどうかな?

 

f:id:arakan_no_boku:20191006144519p:plain

いけてますね。

今回はこんなところで。

ではでは。