Why Use Namespaces 0:00Let's move on to namespacing. So, if we take a look at any of the classes so far, there's no real hierarchy. And by that I mean, if you think of it in terms of a folder structure. And the example I always use is, back in the day, organizing all of your music. Okay, well, you wouldn't want a flat structure there. Really, you would want to organize it by the artist. And maybe even at that point, you would want to further organize it by each of the albums. And that way, if a song by ACDC happens to be the same title as a song by CCTOP, they're not going to clash because they're organized into their own folders. Or we can think of that as namespacing in PHP.they're not going to clash because they're organized into their own folders. Or we can think of that as namespacing in PHP. So, for example, if I go into my core, yeah, we have a request class or an app class. But maybe another class we create is also called app. Or maybe a package we pull in has a class called app. Well, right now, they could clash. Because we have two classes with the exact same name, there's going to be a problem. Which one do we actually want to load? So, generally, it's a good practice to organize these into folders or namespaces. So, in this particular case, yeah, you can basically do anything you want.So, generally, it's a good practice to organize these into folders or namespaces. So, in this particular case, yeah, you can basically do anything you want. But we could organize it by the name of our application, like layer casts. Or we could just call it app. And then we designate each folder using a backslash. So, using the music example, you might say ACDC, and then a folder for rock or bust, and then the name of the song. Right? So, if we were to change that over here, well, the app would be sort of like the top-level namespace. Applying Namespace Hierarchy 1:34So, if we were to change that over here, well, the app would be sort of like the top-level namespace. The next namespace would be, well, what is this? This is our controllers. So, let's call it that. So, now, it's not pages controller. The class path is app controllers, pages controller. All right? We have a better hierarchy here. Now, of course, you're generally going to do this with your classes.We have a better hierarchy here. Now, of course, you're generally going to do this with your classes. You could do it with function files as well. But for now, just think of it as classes. And that means things like your views, there's nothing in namespace here. So, you don't have to worry about that. Now, what about within the core directory? Well, maybe we could also do something like app core, if you want. If you want to do a different top-level entirely, you can. It all just depends.If you want to do a different top-level entirely, you can. It all just depends. In this case, maybe we could do app core. And then it would be the same thing for any of the others in this hierarchy. And then further, if you had another directory within here, maybe services or something like that, then a class within that file would be app core services. So, generally, kind of a common practice is to have your namespace mimic the folder structure. Okay. Fixing Autoload References 2:41is to have your namespace mimic the folder structure. Okay. So, let's go back. We have users controller, app controllers, and I think we already did pages controller. Okay. But now, we're going to have to change a couple things. If we switch over to Chrome, we get an error. Class app not found. And, of course, it's not found, right?Class app not found. And, of course, it's not found, right? You changed it. It's no longer app. It's app core app. So, it sounds like if we go back to our bootstrap file, we need to update these references. Now, we could do it in a couple ways. We could do it individually. We could do that.We could do it individually. We could do that. App core app. And in this case, don't let the duplicate app confuse you. This is the top level namespace, and this just so happens to be the class name. But it could be container. It could be application. Anything you want. So, yeah, we could do this.Anything you want. So, yeah, we could do this. But as you can see, you'd have to reference it over and over. And that can get a little messy. So, another option, if I undo, is to say use at the very top. So, this is sort of like an import. We want to use this class anywhere within the file. And now, because we've imported it at the top, if we reference app, PHP will know, oh, they're looking for this file.if we reference app, PHP will know, oh, they're looking for this file. But still, if we come back and give this a refresh, no, that's not going to work. Let's try switching to the terminal and doing a composer dump autoload. Okay. And refresh. And there we go. Now, once again, because we're autoloading all of the filesAnd there we go. Now, once again, because we're autoloading all of the files using just a general class map approach, now you can see these have been uploaded. So, this full namespace class is located within this file. Anyways, if we switch back, now I can't find another file, the router. So, if we come down into, let's close this up, into our index file, once again, router. So, again, we could do app core. But then you can kind of see this gets a little more messy.So, again, we could do app core. But then you can kind of see this gets a little more messy. It's not as clean as we would want. But yeah, I mean, this would be fine. But for your users, especially, it's a little more to take in if they keep having to reference these long paths. So, yeah, that's something to think about. But yeah, in this case, I might pull them in at the top. And here's a little tip. You could do this.And here's a little tip. You could do this. So, just pull in each of them. And I guess we only have one in this case. That would be fine. Or in PHP 7, we can do a comma separated list. So, we could do something like this. And that says we want access to app core router, but also app core request. So, if we were to come back and give that a refresh, yeah, now we've moved on to the next error. Namespacing Controller Resolution 5:10So, if we were to come back and give that a refresh, yeah, now we've moved on to the next error. It can't find the pages controller. Okay, well, let's see what's going to happen here. We're going into our router. And if we come down, here's where we direct the traffic. Now, you'll remember in our routes file, we're not referencing the full class path. So, that means, yeah, you could do something like this, app controllers. Come back, give that a refresh. And now it's working like it did before.Come back, give that a refresh. And now it's working like it did before. And that's totally fine. What you may find, and this is going to be true for Laravel when I show you that, is it's kind of a shame because basically all of your controllers will be stored there. And that's a lot to type out when you're building an app. So, to streamline things as much as possible, you could always make that implied. And we're going to hard code that in here, but it could also be like a configuration item you could set. So, if we come back to call action, we could do something like this,but it could also be like a configuration item you could set. So, if we come back to call action, we could do something like this, where we say app controllers and then the controller. But actually, in this particular case, we would need to escape it. Let me show you this real quick. Switch to Chrome. Yeah, notice you're going to see the braces here. So, yeah, in this case, it's because we're escaping it. When you proceed a symbol with a backslash, that's your way of saying, no, don't treat this as any specific important PHP symbol.When you proceed a symbol with a backslash, that's your way of saying, no, don't treat this as any specific important PHP symbol. I literally just want a curly brace in this case. But that's kind of misleading. We don't want it. We actually want a backslash and then we want to echo out the variable. So, in that case, you would use double slashes here. And for that reason, you'll often see people just default to doing double backslashes. Up to you. But anyways, if we give that a refresh, now we have our full class path, which we can new up.Up to you. But anyways, if we give that a refresh, now we have our full class path, which we can new up. Anyways, now you can just override it and say, create a new controller. And that should now work. Great. So, yeah, all we're doing here is we are assuming a convention. It's your own framework. All of your controllers will be stored here. So, now, if you come back to your routes file, these can remain as simple as possible. So, about, about our culture. Importing Classes in Namespaces 7:01So, now, if you come back to your routes file, these can remain as simple as possible. So, about, about our culture. Actually, we got rid of that entirely. Our contact page. And then we had a user's page. Okay, but now that's failing because, once again, it can't find app controllers app. And this is a very common mistake newcomers make, especially when using something like Laravel. So, let's figure out what the problem is. We're going to go into user's controller.So, let's figure out what the problem is. We're going to go into user's controller. And here, we are referencing the app class. But why is it saying it couldn't find app controllers app? We know it's within app core app. Okay, so here's the important thing to understand. When you reference this class, by default, PHP is going to look within the current namespace. We didn't import it. So, it thinks, oh, we're looking for, essentially, this. Or like this.So, it thinks, oh, we're looking for, essentially, this. Or like this. When you begin a class path with a backslash, that's your way of saying, don't take into account the current namespace. I'm starting from the root of my application. So, anyways, it's looking for that. But, of course, that doesn't exist. So, an error is thrown. So, it sounds like we need to say, no, the class that I want to use is app core app. And notice that keyword, use.So, it sounds like we need to say, no, the class that I want to use is app core app. And notice that keyword, use. So, we say it right here. Use app core app. Now, whenever we reference this app class, it's going to look here. And if I come back and refresh, it should work. That's all there is to it. It's just not that complicated. And also, notice the convention here with your class. Generally, following what we would call a PSR-2 standard,And also, notice the convention here with your class. Generally, following what we would call a PSR-2 standard, it's just a boring standard that most people follow. You'll have your namespace at the top. Then you will import anything. And often, for projects, you'll see countless. You'll see a dozen different lines where you import classes. It's kind of annoying, honestly. But it'll do the trick. And then you define your class. Models and MVC Homework 8:53But it'll do the trick. And then you define your class. Now, we're basically done. I'm going to give you a quick bit of homework. I want you to pause after I say this. But then I'll give you the answer right at the end of this video. So, imagine that you're going to add a new directory for your models. And a model, we can talk about that in the future. It's basically a class or set of classes that are responsible for something that is importantIt's basically a class or set of classes that are responsible for something that is important to what we would say is your domain or the thing that your application is. So, if you're building a project management tool, you might have a model called project. You might have a model called task. And these are things that are responsible for sometimes persistence, but sometimes just important things that your application or domain can do. For example, if a project can add a task list, well, maybe in your project class, you would have a method called addList.For example, if a project can add a task list, well, maybe in your project class, you would have a method called addList. That's sort of a quick and dirty example of what you might reach to the model for. And that way, your controller can sort of be like the middleman. It delegates. So, in this case, if the user visited in the browser, if they visited slash projects slash one, the controller would say maybe to the model, oh, go find me that project. And then if the user is asking to add the task list,oh, go find me that project. And then if the user is asking to add the task list, the controller might tell the model, yeah, can you go ahead, doing something like this, can you go ahead and add a new list where the data or the relevant data comes from a form the user fills out? The controller delegates. But the model will actually do the work of adding the list and persisting it. And then finally, the view is generally just a template. It will present the results to the user.And then finally, the view is generally just a template. It will present the results to the user. And this is basically MVC. M for model, V for view, C for controller. Anyways, your homework is create a models directory, add any class you want. If you want to stick with project, that's fine. And then try to figure out what the namespace should be. Okay, so this should be pretty easy to you. If not, you might want to go back and watch the video again.Okay, so this should be pretty easy to you. If not, you might want to go back and watch the video again. We would create a models directory. And we're going to call it project.php. I'll save it. All right. We'll create the class, project. However, we do want to namespace it. So we could say namespace app models. And that's it.So we could say namespace app models. And that's it. But now this might raise the question, do you remember when I said that generally your namespace will mimic your folder structure? But we don't have an app folder, do we? You're right. We don't. Everything is top level. So what if we were to... Restructuring Into App Folder 11:34Everything is top level. So what if we were to... And real quick, let's reveal this in the finder. What if we set up a new app directory? And within there, we would have anything that is unique to the application. So we might put the controllers, the models, the routes, and the views. Okay, now you might find that this cleans things up a bit. We have our core. And this is sort of like your custom framework. It's the nuts and the bolts.And this is sort of like your custom framework. It's the nuts and the bolts. It's the plumbing and the wiring and the electric. But it's not the application itself. The application itself is stored here. This is where you decide, okay, when the user hits this route, then we're going to hit that controller. That controller will delegate. And then it's going to load this view. And the view is going to display any relevant HTML for the user.And then it's going to load this view. And the view is going to display any relevant HTML for the user. So this is a good place for this stuff to go. The vendor, once again, that would be any composer packages that you pull in that can stay at the top level. And often, it's a good practice to separate the public directory from the app. And that way, and this requires a little more server knowledge, but in that way, they can't get access to any files or data that they shouldn't have access to. So this would be our document route.that they shouldn't have access to. So this would be our document route. And incidentally, the index file in real life would probably go within there. Okay, but yeah, we can see this cleans things up quite a bit, I think. Now we have changed our directory structure, right? So our class map is no longer right. It's looking in a controller's pages controller, when it should look within app controllers. So once again, let's do composer dump autoload to rebuild those files. Anyways, if we rerun it like we did, now everything's pointing to the proper path.So once again, let's do composer dump autoload to rebuild those files. Anyways, if we rerun it like we did, now everything's pointing to the proper path. And let's see what we have to do. So back in the browser, it can't find the routes file anymore. Okay, let's see. Right here, the routes file is no longer in the root. It is within the app directory. Okay, refresh. And now it's having trouble locating our views. So let's see.And now it's having trouble locating our views. So let's see. Into the controllers, into the users controller. Here's the current method that we're triggering. Okay, it's trying to load the view, but it looks like it can't find the file. So let's figure out what the problem is. In our bootstrap file, we had a couple helper functions right here. Let's change it to the app directory. All right, come back. And now everything's working like it did before. Transitioning to Laravel 13:51All right, come back. And now everything's working like it did before. And that's it. So really, we've gotten to a fairly clean point. So you've built your own custom framework. But like I said, I think this is really good for learning purposes. But when I start a new project, I'm not using a custom framework. A lot of people do. A lot of people swear by it. But not quite for me.A lot of people swear by it. But not quite for me. I want somebody else, or in fact, a massive group of people across the world, to be responsible for the plumbing and electricity. So that I don't have to worry about that. Because for me, to make money, what I care about is this directory. Not as much as this directory. I am for learning purposes. But in terms of making money and putting food on the table, this is what is most important. So the more you can offload this to other people, the better in my mind.But in terms of making money and putting food on the table, this is what is most important. So the more you can offload this to other people, the better in my mind. So in the very next episode, I'm going to introduce you to Laravel. And we're going to finish up the series. And I'm going to give you your next steps at that point. I'll see you then.
