Project Structure Overview 0:00Okay, in the last lesson, we successfully installed Composer and Laravel and booted up our first screen. Now let's take things a step further and start talking about this idea of MVC. What exactly does that refer to? Well, I will switch back to my terminal and hit Ctrl C to cancel the server. And now let me edit this within my editor. If working along, feel free to use whatever you want. So here is our directory structure. We can see we have a bunch of files like our composer.json file. Think of this as the configuration file for Composer.We can see we have a bunch of files like our composer.json file. Think of this as the configuration file for Composer. We have a composer.log file. Most of the time you can ignore that. We also have things like a readme, a phpunit configuration file, pretty basic stuff there. But what I want you to focus on right now is the app directory. Most of your work is going to take place within this directory. Now at first, admittedly, if you come from procedural code, this can feel a little bit overwhelming. But all you have to do is just take it one folder at a time and very quickly it will Understanding MVC Responsibilities 0:57overwhelming. But all you have to do is just take it one folder at a time and very quickly it will become second nature. So when we talk about MVC, that refers to models, views, and controllers. It's a way to divide your code up into specific responsibilities. So think about your typical procedural code. You would probably have something that connects to a database. Sometimes you might even put this on top of some HTML. Maybe you also have some code here that connects to an API. Next somewhere within your HTML you have something that calls functions and etc.Maybe you also have some code here that connects to an API. Next somewhere within your HTML you have something that calls functions and etc. So very quickly you can see that we have all of these different responsibilities mixed up. We're connecting to the DB. We're querying an API. Maybe we are modifying an image. Maybe we are connecting to a billing provider. And within our HTML itself, we're doing a lot of work as well. So this makes our code very difficult to grow and change.And within our HTML itself, we're doing a lot of work as well. So this makes our code very difficult to grow and change. The MVC architecture, on the other hand, divides all of these things up into their own responsibility. You will have one class that's entirely responsible for connecting to your database. Maybe you will have another class for a specific API. And then your view, and at least based upon the modern frameworks of today, you can think of a view as your static HTML. Maybe you will give your view some data. However, beyond that, the view doesn't really have a brain. Think of it as the scarecrow from Wizard of Oz. Defining Routes and Views 2:20However, beyond that, the view doesn't really have a brain. Think of it as the scarecrow from Wizard of Oz. It doesn't know how to do anything. It just knows how to receive data and display it to the user. All right, so what shape might that take? Well, let's do a little example here. If I scroll down, you'll see routes.php. This is where you define all of the routes that your application is going to respond to. It's possible that you're used to simply creating a folder structure that mimics theto. It's possible that you're used to simply creating a folder structure that mimics the URI that you want to respond to. For example, if you wanted to respond to billing.index.php, well, you would create a billing folder, and then you would also create an index.php file within it. That's sort of the traditional way to go about it. However, once again, that just doesn't scale overly well. Instead, within our routes file, we can define specifically what we want to match and then what we want to do in response. So let's get rid of some of this stuff here, and Laravel includes one basic route to getwhat we want to do in response. So let's get rid of some of this stuff here, and Laravel includes one basic route to get us started. So take a look at this. We are using Laravel's route class. This is actually called a facade, but don't worry about that too much just yet. So here we are saying when the user makes a GET request, and think of that just as loading a page, then we want to do what's represented here within this closure. So for example, if I commented this out and we simply returned foo, well, if I open a new tab, boot up our server again, and then view that in the browser, sure enough, weSo for example, if I commented this out and we simply returned foo, well, if I open a new tab, boot up our server again, and then view that in the browser, sure enough, we get foo. Now this is an important thing to understand. You always want to ensure that you return your response. Now in this case, so what is going on here? Well, view is the name of our class, or facade like I said, and now think of this as saying we are going to make or create a new view, and what is the name of the view that we want to create? Well, it's called hello.to create? Well, it's called hello. Now when we call this code, Laravel is going to interpret that as I want to load the view that is within the app directory, views directory, and then it should be called hello.php or hello.blade.php. Now blade is a template engine that we will go over shortly. However, because a view will always be contained within the views directory, Laravel allows us to simply strip that off, and we can also strip off the extension. All right, so let's see if we can find that file. Back within the app directory, here's views, and there it is.All right, so let's see if we can find that file. Back within the app directory, here's views, and there it is. So we told Laravel that when you load the homepage, this is the view that I want you to load. Let's change it up a bit. How about we instead want to respond to foo slash bar. All right, let's try it. Come back. So now the homepage, well, we aren't responding to anything, so Laravel will throw a not found HTTP exception.So now the homepage, well, we aren't responding to anything, so Laravel will throw a not found HTTP exception. But now we can reference foo slash bar, and we load the same thing. So very quickly you can see how much control you have over your URI structure. Anyhow though, let's bring it back to the way it was before, and now let's update our hello view. Now I will delete everything in here and replace it with some dummy data. Now within here, we will simply say, hello there, and save it. Now if I come back to the browser, everything is looking great. Now what if we instead want to say something like hello and then your name? Passing Data to Views 5:27Now if I come back to the browser, everything is looking great. Now what if we instead want to say something like hello and then your name? Well, traditionally you might place it at the top of your HTML page, and you could say name equals, and we will use my name here, like so. And now within your body here, you could say hello, and then open up PHP and echo name. You've seen this many times, right? Now if I come back, sure enough that works. But now we're thinking more in a mature fashion, and we don't want to be creating these variables directly within our view. That is not the responsibility of the view.directly within our view. That is not the responsibility of the view. So instead, we will remove this entirely. And now we will instead define the variable either within a controller, which we will go over shortly, or we can do it right here within our route. Now I will say name, once again set that to my own name, and then I will say I want to create that view, however I also want to pass some data to that view. So I will say create the view, and also pass through a variable called name, and make that equal to this name that I created here. Now if we go back to our view, this name variable will be accessible. Using Blade Templates 6:31equal to this name that I created here. Now if we go back to our view, this name variable will be accessible. Let's come back, load the page, and it still works. So now our view is significantly cleaner, and it doesn't have to be responsible for things that it shouldn't be concerned about. So let's quickly touch upon Blade. Now really, at its core, PHP is a templating engine, but it didn't really grow to be a good templating engine. Luckily, Laravel offers Blade, which offers a much nicer syntax. To activate Blade, so to speak, we can rename our file from hello.php to hello.blade.php.Luckily, Laravel offers Blade, which offers a much nicer syntax. To activate Blade, so to speak, we can rename our file from hello.php to hello.blade.php. Now we can update this like so. Rather than opening up PHP tags, we could simply say curly brace curly brace, the name of the variable, and close curly brace twice. So think of this as identical to saying PHP, echo, and then whatever the name is, because that's exactly what it's going to be parsed to. So now, if I update this, that's going to work. Just keep in mind, if it doesn't seem to be working for you, well, make sure that the file has a .blade.php extension. Moving Logic to Controllers 7:34Just keep in mind, if it doesn't seem to be working for you, well, make sure that the file has a .blade.php extension. Alright so we've discussed the basics of routing. We've discussed the basics of creating views, but what about controllers? Well, if you want, you can treat Laravel like a lightweight framework. In fact, if you didn't want to use controllers at all, you could get away with that. But you'll find that if you're building anything beyond the most basic, simplest of applications, you're probably going to want to leverage controllers. So how could we do that? Well, instead, we could rewrite this and say when the user requests the home page, thenSo how could we do that? Well, instead, we could rewrite this and say when the user requests the home page, then we want to reference some kind of controller. Well, if we were building the typical static-ish website that has a home page, an about page, contact page, maybe we could create a pages controller. Now we need to tell Laravel what the name of the controller is, pages controller, but also we need to tell it the name of the method that we want to call. In this case, why don't we call it home. Now let's create that file. If I open up my controllers directory, you'll see that Laravel includes a base controller,Now let's create that file. If I open up my controllers directory, you'll see that Laravel includes a base controller, and it also includes a sample controller to get you started. So I will let you have a look at this, but for now, we will create our own. Pages controller dot php, and then within here, we give it the same name, pages controller, and we want to make sure that it extends our base controller. So let's do that. Extends base controller. Next, remember how within our routes file, we gave it a method name called home. We need to create that now.Next, remember how within our routes file, we gave it a method name called home. We need to create that now. So I will create a method called home, and now we can treat this in the same way as we did from our routes file. In fact, I could just delete that. Let's get rid of all of this here. And now if I go back to my pages controller, I can paste that in, like so. Okay, let's try this, and we will update the variable name to John. Okay, if I reload the page, everything works exactly the way it did before, but now our routes file is a lot cleaner.Okay, if I reload the page, everything works exactly the way it did before, but now our routes file is a lot cleaner. So you might be asking, well, how do you know when to use controllers and when to simply use routes with closures? Well, the basic rule of thumb is if you're building a simple application, almost like a throwaway application, something you're going to whip up in a day or two, well, sure, you could use route closures for that. However, if you are building an application that you expect to maintain for a good period of time, well, you know what? Definitely use controllers.of time, well, you know what? Definitely use controllers. So to finish up, let's do one more. What about when the user requests the about URI? Well, in that case, we will load pages controller, and we will call this about. If I now return to our pages controller, we can create that method called about. And once again, I need to make sure that I return from this method. So I'm going to return a new view called about, and do we want to pass anything through? Well, you can if you want, if you are working along, but I will keep it like this. So now, if I come back and we try to load about, let's see what happens.Well, you can if you want, if you are working along, but I will keep it like this. So now, if I come back and we try to load about, let's see what happens. Well, Laravel is going to let us know, hey, that view you want me to load does not exist. So that's our next step. We open up our views directory, we will create about.played.php, and just to save myself some time, I'm going to copy all of that, paste it in, and then on line 9, we will say about page. Now notice how I repeated all of that HTML? Well, that's a bad practice, and we will fix that in a future lesson. But nonetheless, we've created the view, so now we have an easy way to view various pagesWell, that's a bad practice, and we will fix that in a future lesson. But nonetheless, we've created the view, so now we have an easy way to view various pages like you might be used to from your procedural code. All right, and I think that's going to do it for this lesson. We covered routing, views, controllers, but what about that letter M? Well, that stands for models. However, I want to dedicate a full lesson to that, so we'll do that in the next video.
