Laravel 5の新機能

数か月前、私が働いているスタジオで、チーム全体がLaravelに移ることを決めました。 過去数年間で、このフレームワークの人気はたゆまぬ力で成長し、結局のところ、無駄ではありませんでした！



私は自分自身をPHPとフレームワークの第一人者とは考えていません。 その前に、私は最初と2番目のゼンドである不滅のbitrixで数回働き、YiiとSymfonyに出会い、自分で自転車を発明しましたが、そのたびに漠然とした不満を感じていました。



たとえば、Zend Frameworkを使用することで、タスクをすぐに完了し、悪夢のようなことを忘れたくなりました。 このフレームワークの支持者は確かに私に同意しませんし、決して彼らの選択を批判したくありません。 それぞれに。 Zend Frameworkのおかげで、コードは人によって作られたものではなく、人のために書かれたものではないといつも感じていました。



同じタスクをより簡単かつエレガントに解決できるといつも思っていました。 私が書きたいフレームワークを見つけたかった。 手の甲のように学び、プログラミング、新しい何かの作成など、自分がやりたいことをすることができました。 私はすべての大工が好きなハンマーを持っていると思います、そしてプログラマーに対するそのような欲求は非常に自然です。 PHPで書いている私たちの多くは、RubyのRailsやPythonのDjangoをうらやましく見ていません。



最後のストローは、PhpStorm 8 Bladeテンプレートの新しいバージョンとSource＆Testディレクトリのサポートの拡張についてのJetBrainsからの投稿でした。 このIDEでは、Laravelで最初のプロジェクトを作成しました。



Laravelと仕事をした後、私は自分が探していたものを見つけたことに気付きました。 おそらくそれが、「あなたが到着しました」というスローガンがララヴェルのシンボルになった理由です。



初日から、ドキュメンテーションやコミュニティから心地よく驚かされることはありません（この記事を書いているときに問題に遭遇したとき、コミュニティのオンラインチャットに行き、問題を説明し、個人的に答えました（！）プロジェクトをサーバーに配置した後に使用できる、または使用する必要のあるさまざまな利点。



しかし、私の記事はそれについてではありません。 Laravelの長所については十分に書かれています。



この記事では、11月に公式にリリースされるLaravelの新しいバージョンについて書きたいと思いますが、Composerから今すぐダウンロードして試すことができます。



当初、バージョンは4.3と呼ばれていましたが、新しいディレクトリ構造とコードのいくつかの重要な変更により、作成者はバージョン5.0を発表することにしました。



これらの変更があなたにとってどれほど深刻であるかを判断します。 それでは、実際にLaravel 5が私たちに準備しているものを見てみましょう。

設置

新しいバージョンのインストールは、基本的に古いバージョンと変わりません。 開始するには、composer.jsonファイルに行を追加してLaravel 5をダウンロードします

"require": { //... "laravel/framework": "5.0.*@dev" //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、composer updateを実行すると、操作の最後に最新バージョンがインストールされます。

構造

Laravel 4とLaravel 5の構造を見ると、すぐに違いに気付くことができます。 まず、Config、Tests、Storage、およびDatabaseフォルダーがAppフォルダーからルートに移動されました。 新しいリソースディレクトリが登場しました。







論理的な疑問が生じます。Appフォルダーには何が残っていますか？



これで、Appフォルダーには、アプリケーション自体のロジックのみが保存されます。 したがって、開発者はほとんどのLaravel開発者が以前に行ったことを合法化しました。モデルフォルダーを削除し、この特定のプロジェクトの開発に関連するすべて（モデル、チーム、イベントなど）に個別のディレクトリを作成します。 まず第一に、これにより、フレームワーク自体のコードと開発者が記述するコードの間に明確に線を引くことができます。



Appフォルダには、デフォルトで3つの新しいディレクトリがあります。 Consoleディレクトリはコンソールコマンドのクラスを対象としており、Service Providersフォルダーにはサービスプロバイダーのクラスが含まれ、Httpフォルダーにはコントローラー、フィルター、ルーティングに関連するすべてが含まれます。







次に、Httpディレクトリには3つのフォルダーがあります。アプリケーションコントローラー用のコントローラー、個別のクラスとして作成されるルートフィルター用のフィルター、および以下で詳細に説明する要求フォルダーです。

Viewフォルダーは、Langローカライズフォルダーと共にResourcesディレクトリーに移動しました。

新しい構造は珍しいように見えるかもしれませんが、数日後にははるかに便利であることに気付くでしょう。



構造の変更に関連して最初に発生する可能性のある疑問は、名前空間とクラスのオートロードに何が起こったのかということです。

名前空間

Laravel 5は公式にpsr-4標準を公式に使用しています。これは、正しい名前空間を持つAppフォルダー内のすべてのクラスがオートローダーで使用できることを意味します。

したがって、このフォルダー内のすべてのクラスがApp \ *ディレクトリ名で始まることを確認し、ファイルのアップロードの問題を永久に忘れてください。



一方、psr-4を使用すると、ファサードへのアクセスには、グローバル名前空間（\ Auth :: * method name *または\ Events :: * method name *など）からのアクセスが必要になります。

この点に関して、ファイルの先頭でuse \ front-nameコマンド（たとえば、\ View）を使用してファサードをインポートするか、バックスラッシュ経由でアクセスする必要があります。



さらに、コントローラーの名前空間を指定する必要があります。 すべてのコントローラーに文字列が含まれていることを確認してください

 namespace App\Http\Controllers;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

抽象コントローラー名前空間を使用します

 use Illuminate\Routing\Controller;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BaseControllerをすべてのコントローラーの親クラスとして使用する場合は、最後の行をそこに配置して、すべてのコントローラーがこの名前空間にアクセスできるようにします。



アプリケーションルートフォルダー

アプリケーションのメインフォルダーにアプリとしてアクセスしたくない場合はどうなりますか？ Laravel 4の多くがそうであったように、アプリケーションロジックが格納されているディレクトリにアプリケーション自体の名前で名前を付けた場合はどうでしょうか。



開発者もこれを提供しています。 コマンドラインで$ php artisan app：nameとアプリケーションの希望する名前を書くだけです。 Laravelは、必要なファイルの名前空間と構成ファイルの設定を個別に変更します。



サブディレクトリを使用する場合は、次のように2つのバックスラッシュを使用します

 $ php artisan app:name MyAppName\\HabrProject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、新しいファイルnamespaces.phpがConfigフォルダーに現れました。このフォルダーには、アプリケーション全体の名前空間とファイルへのパスが登録されています。 起動に問題がある場合に便利です！

メソッドパラメータの実装

Laravel 5のもう1つの強力な革新は、メソッドパラメーターの導入でした（メソッドパラメーターインジェクションまたは単にメソッドインジェクション）。

以前は、コントローラなどのモデルクラス（リポジトリなど）が必要な場合、IOC Container Dependency Injectionを使用できました。つまり、クラス名をコントローラコンストラクターに渡し、オブジェクトプロパティに割り当てました。

Iocコンテナーはこのクラスのインスタンスを独自に作成し、アクセスしたコントローラープロパティに戻りました。 そしてそれはクールでした。



たとえば、次のように：

  class FeedController extends BaseController { protected $feedbackRepository; /** * @param FeedbackRepository $feedbackRepository */ public function __construct(FeedbackRepository $feedbackRepository) { $this->feedbackRepository = $feedbackRepository; } public function index($id) { $feed = $this->feedbackRepository->getFeed($id); return View::make('feed.index', compact('feed')); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、1つのメソッドのみでオブジェクトが必要な場合はどうでしょうか？ メソッドの1つだけで使用される場合、コントローラー全体のコンストラクターでオブジェクトのインスタンスを作成するのはなぜですか？

そのため、Laravel 5では、メソッドパラメーターの導入が登場しました！

これで、任意のコントローラーメソッドでクラスを指定でき、Iocコンテナーを介してそのメソッドに自動的にアクセスできるようになります。 例は次のようになります。

  class FeedController extends BaseController { public function index(FeedbackRepository $feedRepo, $id){ $feed = $feedRepo->getFeed($id); Return view('feed.index', compact('feed') } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれだけです！ 魔法のように、Iocコンテナ自体がリポジトリを見つけて接続します。



しかし、このイノベーションの真の力は、別の新機能と併せて感じることができます。

リクエストとフォームリクエスト（FormRequests）

App \ HttpディレクトリのRequestsフォルダについて話していたことを覚えていますか？ それでようやく彼女に着きました。

Laravel 4.2でフォームを送信するときにユーザー入力を検証した方法を思い出してください。



Laravelで働いていれば、Validatorの外観を知っているはずです。

ユーザーから受け取ったデータを検証するための強力な機能を提供します。 ただし、開発者ごとに使用方法が異なります。 誰かがコントローラーでバリデーターを使用し、

誰かがモデル内の検証ルール（配列ルール[]）を書き留め、isValidメソッドを使用しました。



忘れてしまいます。Laravelは、フォームリクエストを処理するための独立した抽象化レベルを提供します。

仕組みを見てみましょう。

コマンドラインで「php artisan make：request MyRequest」と入力すると、フレームワークがフォームリクエスト用のテンプレートを生成します。



FormRequestクラスを継承するこのクラスには、authorizeとrulesという2つのメソッドのみが含まれています。

ルールは、Laravel 4と同様に、フォームの検証ルールを記述できる配列を返します。

authorizeメソッドはデフォルトでfalseを返します。

このクラスに関連付けられたフォームを送信しようとすると、ブラウザーで禁止ページ（禁止）が取得されます。



したがって、authorizeメソッドは、フォームにアクセスするユーザーにフォームを送信する権利があるかどうかを確認します。 たとえば、ユーザーは自分が書いていない記事を編集する権利を持っていますか？ ログインしていない場合はコメントを投稿しますか？ ここで、チェックを配置する必要があります。



ユーザーのウォールにステータスを公開するフォームがあるとします。 ステータスフィールド（通常の入力タイプ= 'テキスト'名= 'ステータス'）が必要で、たとえば20文字含まれている必要があります。 また、ユーザーが自分のウォールにステータスを公開していること、つまり、ユーザーのページのIDが投稿の作成者のIDと一致していることも確認する必要があります。

この例では、バリデータクラスは次のようになります。

 namespace App\Http\Requests; use Illuminate\Foundation\Http\FormRequest; use \Auth; class AddFeedRequest extends FormRequest { public function rules() { return [ 'status' => 'required|min:20', ]; } public function authorize() { return Auth::id() == $this->route->parameter('id'); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、上記で説明したメソッドパラメーターの導入で、フォームの送信を担当するコントローラーメソッドのパラメーターでクラス名を指定するだけで十分です。

RESTコントローラーを使用する場合、これがストアメソッドになります。

  public function store(MyRequest $request) { //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれだけです！ 他に何もする必要はありません！ Laravel自体がフォームを検証し、検証が成功するとコントローラーメソッドに含まれるコードを実行します。 繰り返しますが、フォームの検証に失敗した場合、storeメソッドからのコードは1行も実行されません。 私の意見では、これはめちゃくちゃクールです！

発電機

コマンドラインでphp artisanと入力すると、makeというまったく新しいセクションが表示されます。

myRequestクラスを生成するためにすでにそれらの1つを使用しています。 さらに、make：コマンドは、コントローラー、コンソールコマンド、

フィルター、移行、サービスプロバイダー。



特にphp artisan make：authコマンドを強調したいと思います。 このジェネレーターは、各新規プロジェクト（ユーザー認証システム）で繰り返し行ったことを行います。



ここで実行すると、Laravelが2つのコントローラーを作成することがわかります。1つは承認を担当し、もう1つはパスワードの回復、パスワードリセットの移行、ログインおよび登録要求の2つの検証クラスを担当します。 1つのコマンドと認可テンプレートが準備できました！

ルートキャッシング

ルートチームもセクション全体に成長しました。 ルートのリストを表示するには、php artisan route：listと入力する必要があります。

ここで、新しいルートであるcacheコマンドに気付かないのは難しいことです。 非常に簡単なことを行います-ルートをキャッシュします。

このコマンドを実行すると、routes.phpファイルがstorage / metaフォルダーに表示されることがわかります。 ルートのキャッシュが含まれています。 これで、Laravelはまずメインのhttp / routes.phpファイルではなく、それにアクセスします。



これは開発中にはほとんど役に立ちません。少なくともそのような状況を想像するのは難しいですが、展開中、プロジェクトが既に書かれており、新しいルートがほとんど追加されない場合、これは非常に役立ちます。

契約

Laravel 5のすべてのコンポーネントは、現在、light / contractsフォルダーからのこのインターフェースを実装しています。 したがって、開発者は、アプリケーションをより柔軟にし、Laravel自体への依存を少なくしようとしました。



Laravel 4には、タイプヒントインターフェースに関する問題がしばしばありました。 メソッドのパラメーターで特定のインターフェイスを実装するオブジェクトのインスタンスを指定した場合、IOCコンテナーはそれを依存性注入と見なし、クラスのインスタンスを作成しようとしたため、エラーが発生しました。



この問題を解決するには、app :: bindを使用して、インターフェイスをインターフェイスの特定の実装クラスに直接バインドする必要がありました。 ただし、これは、たとえば単体テスト中など、依然としていくつかの問題を引き起こしました。

Laravel 5では、ファイルの先頭で使用してインターフェースを使用するだけで十分です（たとえば、Illuminate \ Contracts \ Mailerを使用します）。タイプヒンティングは正常に機能します。



これにより、特定の実装クラスに縛られることなく、より柔軟なアプリケーションを作成できます。



将来、標準のLaravelモジュールとは異なる別の認証モジュールを接続する場合はどうなりますか？ 別のキャッシングモジュール？ 手紙を送る？ コントラクトフォルダーからインターフェイスを実装していることを確認し、型ヒントインターフェイスに基づいてコードを記述します。

新機能アシスタント

プロジェクトで何度も使用する些細なこと：ビューファイルをアタッチすることは、ビュー関数（「ビュー名」）で利用できるようになりました。 古いView :: makeメソッドも機能しますが、今、上で述べたように、バックスラッシュを介してアクセスする必要があります。



同じ運命がリダイレクト::へ-リダイレクト（ 'ルート'）を書くことができるようになりました。



通常の作業ツールにおける他の変更の中でも、HTMLおよびFormのファサードが標準のLaravelパッケージに含まれなくなったことに言及する価値があります。 あなたがそれらに慣れているなら、恐れないでください、あなたは作曲家を通して簡単にそれらを接続することができます。

社交界

Laravel 5には、Twitter、Facebook、GitHubなどのサードパーティサービスを認証するために設計されたSocialite Betaモジュールがあります。 さまざまなソーシャルネットワークで承認用のプラグインを追加する必要が頻繁にありました。他のフレームワークに同様のツールがあれば素晴らしいことです。 プラグインはオプションであり、依存関係を追加して追加するだけです。 自分で判断すると、プロバイダー構成を作成するだけで、その後、必要なすべてのメソッドがフォームで利用可能になります。

 $this->socialite->driver('twitter')->user();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

必要なことは、ファイルの先頭に適切なクラスを接続することだけです。

Laravel \ Socialite \ Contracts \ FactoryをSocialiteFactoryとして使用します。

近い将来、vkの承認も追加する予定です。

刃

Bladeの変更のうち、重要な変更が1つあります。これは、過去数日間でコミュニティが同様の質問を多数作成したためです。 これで、{{link_to_route（ 'login_path'）}}タグと{{{link_to_route（ 'login_path'）}}}タグの両方がエスケープされ、コードインジェクションのリスクを減らすためにテキストとして表示されます。



代わりに、コンストラクトを使用する必要があります

  {!! link_to_route('login_path') !!}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、Bladeの新しいバージョンへの移行を容易にするために、タグを古いものに置き換えることができます。

ブレード:: setRawTags（$ openTag、$ closeTag）;

その後、すべてのアイデアを書き直す必要はありません。

まとめ

5番目のバージョンは、このエキサイティングな瞬間をまだ延期している場合に、Laravelに精通し始めるべきバージョンです。 プラグインの大部分はすでにフレームワークの新しいバージョンをサポートしており、網羅的なドキュメントはリリースの準備ができています。 私の意見では、Laravelは、近年のphpコミュニティで最も興味深く、有望なプロジェクトです。 彼が毎日ますます多くの支持者を引き付ける方法を見るのは素晴らしいことです。



Laravelの詳細については、次の役立つリソースをご覧ください。



• laravel.com

• laravel.io

• laracasts.com



たぶん私は何かを逃し、それから個人的に書いて、それを修正します。 ご清聴ありがとうございました！ 記事がお役に立てば幸いです。