For any application, you'll need to trigger certain tasks at various points in time. Every month, or every day, or even every half-hour. Traditionally, this can be a confusing task, but not with Laravel!
The best way to become a better coder is to read a lot of code. Let's do that together in this lesson. Now that you understand the fundamentals of scheduling tasks, we'll flex our muscles and dig into the underlying source code to figure out how this all works!
Laravel offers an incredibly powerful eventing system. Likely more powerful than you're aware. Over the course of the next two lessons, we'll both review the essentials and dig into the underlying source code that orchestrates Laravel's event handling.
Now that we understand the essentials of eventing in Laravel, let's once again peel back the curtain and figure out how all of this works behind the scenes.
Laravel 5 includes a comprehensive set of contracts, or interfaces, for all of its various components. This means, for the projects where it makes sense to seek maximum decoupling, never before has such a task been easier.
Based on our learning from the previous episode, it seems as if multiple keys point to the same binding within Laravel's service container. How exactly does this work? Let's once again peel back the curtain, and figure this out.
Middleware offers us a very easy way to manage and filter incoming requests.
Now what about when you need a little more granularity? Sure, we can filter requests to only allow the users who are subscribed to our application, but what if we want to drill down further and specify that they must be subscribed to a particular plan? Well, in these cases, we may leverage middleware parameters.
When you begin a new project, you'll often want to create any number of sample records in your database. Let me show you how easy this process is, thanks to table seeder classes, and model factories (new to Laravel 5.1).
Like we've been doing often in this series, let's figure out how this whole database seeding thing is orchestrated; from the Artisan command, itself, all the way up to the main `Seeder` class. Remember: if you want to be a better coder, read a lot of code.
Think of a job as an instruction, typically queued, that you want to give your application. Rather than throwing all this logic in your controller, assign it a readable name, assign your dependencies, and queue it up!
From time to time, you'll want to create custom Blade directives for your views. In the past, this wasn't the most enjoyable experience; however, today. it's quite a bit simpler!