 Hey everybody, this is Brian and welcome to the 6E tutorial. We're going to be discussing controllers. Okay, so you have a basic understanding of the model view controller and their relationships. This is called a pattern or design pattern. Remember, once again, a controller is what the user uses. It's what the request goes to. We're going to deep dive into the controller and see exactly what's under the hood. So without further ado, let's just pop in here and let's open up your go to your site, protected, and then controllers. And in there you should see, if you've been following along, a controller for each data table that we've created. Okay, why do we need a controller? Before we even look at the code, why do you need it? Remember our pattern. It's what the user's requesting to. So a real world example, mysitevoidromes.com. You see how we got home tutorials, programs, source projects, donate, contact. Each one of these is essentially a controller. For example, you recognize the pattern site slash index. You can tell we're on the site controller. If we click on tutorials, you see it's in the tutorial controller. And of course, the tutorial controller is talking to the tutorial model, which is rendering the tutorial views. Naha, light bulb moment. You understand now why we need this. So very simply, let's open up our teacher's controller. And you can see how it extends controller. That should be the first thing that catches your eye. So there's already code running that we're inheriting. The public layout is layouts column two. What that means is this is the default layout. You can go to view, layouts, and there's column one, column two, and main. We'll be discussing that in future tutorials, but just be aware that by default, you are using column two. You can change that. The code for column two, of course, is this little guy right here. That is the default for how the data is being displayed in the view. Filters. Yee controllers have what are called filters. And a filter is a way of filtering in certain actions. It's not so much a filter like a database filter. For example, access control. We're applying the access control filter. And then post only on delete, meaning when we delete, we're only posting data. We're not actually returning a view. So access control leads us right into our access rules. The access control filters. If you're looking at these, you'll see a distinct difference here. Allow, deny. What this means is we are allowing these views, index and view, and the user's a star. What that means is anybody. It's a wild card. And then we're allowing authenticated users to create and delete. The add symbol is an authenticated user. I'm sorry, create an update. We are also allowing the administrative and delete for admins only. And we're denying everything else. Deny star. So to kind of cement that, let's say we go to a view that doesn't exist. We get a 404 error. And that's because of that explicit deny at the end. Right here. Deny. If we allow, it'll say 404 not found simply because we don't have that view. But we're explicitly denying anything that's not noted here. So let's try admin. Actually, no, I'm sorry. Cat's disturbing me. You try admin. You've noticed the first thing it says is you gotta log in. Well, wait a minute. We're just trying to view the view here. Why are we being told to log in? That goes back into the access rule. The users is admin. So we are forcing them to log in. We'll cover that in future tutorials, but it's really, really important you understand that because that is a cliffhanger. A lot of people get stuck on. Now, if we were to change admin to star and just save it real quick, go back out, we can now access it without logging in. But we're going to change it back the way it was simply because we don't want the whole world to be able to administer and delete records. Now, if you look at the basic structure here, the entire world or star can view only authenticated people can create an update. Only administrators can administrate and delete. Pretty simple. Now, the controller also acts as like a router. If you will, it routes from one place to another. Whenever you see action in front of something, you should instinctively think this is an action the controller is going to take. Action view, meaning it's loading the view. Action create, meaning it's going to load the create view. And action is not explicitly mean it's going to load a view. It's just an action the controller is going to take. You could create action dog and then do something that has nothing to do with the view. But typically an action will display a view. So let's focus in on create here because this is a very good example. We see we have a variable called model equals new teachers. So we're loading the teacher's model and then we're saying if is set, post parameters of teachers, then do something. Let's examine that in depth here. Let's go to teachers. Now we're going to go to create. Now instinctively it's going to tell us, hey, you need to log in. So we can log in as demo as an administrative user per our authentication rights or admin, admin so we can do everything. So we're just going to do admin, admin, log in. And now we are at the create. You can tell because the bread comes, which we'll cover in another tutorial, but home teachers create. So we're going to say Bob Smith create. Now what just happened there when we clicked that create button, as you can see, obviously it created the information and put it in the database. But how did it actually do that? Well, let's go back here. In our action create, we made a new teacher's model. If the post teachers is set, which happens when we click the create button, we're posting it back up to the web server, then we're saying model load attributes post teachers, meaning in that form, there will be teachers information. And let's kind of go back here and view page source form ID teachers form right here. This is what's getting posted up to the server. And what we're doing is we're loading the vape the vape that excuse me can't speak when the cat's rubbing up against me. Wow, kitty. What we're doing is we're loading the information out of this form. See teachers first name. So you've got model parameter. Whoops, model parameter teachers first name teachers last name, loading that data and putting it back into the model. So we're posting it loading it and then we're saying model save this redirect view, meaning we're now taking action and we're routing we're saying redirect the user to the view with this specific information ID equal model ID teachers. You can also say primary key, but that's the primary key of that teacher. So we're viewing the teacher. So if we make another one, let's call it Mary Jane. Notice how it instantly puts us in teachers slash view with the ID of seven, meaning we're viewing that record. If we change this to six, should be the one we just created. Yep, Bob Smith. So that's how the controller really works. And we can kind of just pluck through some of these like the update. You can see what we're doing is we're loading the model and we're calling this load model ID. Well, the load model is just saying teachers model find by PK or primary key and then the ID we're giving it as a parameter. If it can't find it, if models null, we're going to throw a 404 not found. So if we say some obscure number, I know that doesn't exist, 404 not found. And then we're going to return the model if we haven't already thrown the exemption. And as you can see, some of these are when you just without even knowing the framework, you can just look at it and intrinsically know what it's doing like delete this load model, we're loading that exact model. And then we're deleting it. And then we're saying, you know, if not is that get Ajax, then redirect to return Earl. Obviously, we're setting an Earl somewhere. You know, for example, index. Let's actually go to the index because we haven't seen that populated yet. You can see now we've got multiple views of the same data. We're in teacher slash index. So the controller really just routes you from one place to another and takes actions in the background. It's very important to have a controller to separate the logic from the data and the logic and data from the view. Couple last notes here. Perform Ajax validation. This is in almost every controller. Notice it has the teachers dash form. And it's calling validate. That would be for things like, let's log out, go to contact, you notice these little red stars. If it has not null in the database field, it'll do something like this when you go to, you know, modify it. You know, because it can't be null. Now, if I just submit, it'll actually validate it. This is the Ajax validation. We haven't actually posted back. And it's already validating the form before we posted it back. So that and that shows how that works. Another quick tutorial, but we've learned a lot. Don't expect you at this point to really understand all of this. You just need to know the basic components of controller and why they're there. And then from then we can start really getting to know everything really in depth.