 Hey everybody, this is Brian and welcome to the 7th E tutorial where today we're going to be discussing models and no, I don't mean runway models, I mean models out of the model view controller framework. Alright, so we're going to go to your site, go to Protected, go to Models and you should see a file for each table that we've created. Also you'll see some extra ones called forms, contact form and login form. So let's just open up teachers.php. Here a model is a representation of the data, it's not actually the data. You can see that we've got a ID teachers and a first name and a last name. And if you've been following along, you know from the MySQL tutorials, let's actually just do this, we've got our primary key ID teachers, first name, last name. And then in the classes, because we're doing a school representation here, we've got a student ID and teacher ID and name and they are foreign keys for the teachers and students and students is pretty much the same thing as teachers where you just got a first name, last name and primary key. Alright, now we can get back to this. So teachers is extending C active record or actually I should say it inherits C active record. So all of the database goodness is being handled in C active record and you never really have to play around with that at all, you just hand it parameters and it does what it needs to do. I like that simple, easy to use, alright, table name, returning the name of the underlying table that we're modifying, rules. This is the rule set that E must follow. Remember the model and you're going to hear me say this time and time again, the model is the representation of the data. Because we're representing the data, we have to define what the data is going to look like. First name, last name, the length has a parameter of max equal to 255. If you remember, we made first name and last name as vercare 255, so we're saying it's a string that can only be 255 characters long. The safe search parameter, these allow you to search these fields. Means they're safe to search. You have teachers first name, last name. Relations. Relations define the relationship between models or I should say between database tables. Remember a model is once again, yes, I'm not going to repeat it, you know what I'm going to say. Anyways, the relation defines the relationship between those models. For example, classes. Teachers has a relation called classes, which has many classes that relate to teacher ID. Now that sounds kind of cryptic, what does this mean? It means that in the classes model, we can have many classes that point to teacher ID. So let's open up classes. And as you can see, it's pretty much the same thing. Rules are a little bit different. We've got student ID and teacher ID are numerical and their integer only equal true. Name, length 255 and we have our safe search parameters. Now when you go down to relations, that's when things look a little different. You can see in the classes model, we have teachers and students. Teacher belongs to the teacher's table and points to the teacher's ID field in the classes. Remember, classes model, teacher ID, student ID. So what we're really doing is we're building a data relationship here. So if we create an instance of a class and we look up class 106, we can actually point to the teacher and point to the students in that class. Pretty neat, huh? We'll see that in action later on in future tutorials, I should say. All right, let's go back here. Attribute labels. Attribute labels define what is displayed in the view. For example, if we didn't want this to say ID teachers, we could say something else like fuzzy bunny slippers or whatever. And we would define that here. Like if we wanted first name, last name, we could put a space in between first name and last name. Things like that. Allows you to abstract the data even further. Search. This is pretty much where the magic happens for any sort of criteria. This is efficiently saying select star from blank, where, and then you have a specific criteria. So you have what's called a CDB criteria class, which you're using. And you're saying criteria compare and then you want, you know, this is a basic search that's going to return all records. You can define your own CDB criteria. However you want and create your own queries. But this is the search function within the model, which will return all rows in that model. All right, now you notice how they're true? And let's see. Return, see active data provider. You're actually just returning the data provider with the criteria in there. And you can modify the criteria later if you really want to. Last but most certainly not least is we are just returning a model class here. So we're returning a reference to it. That was a mouthful. Now that is the C active record. C active record, whenever you see active record, instinctively think database. Because what you're really doing is you're talking to the database. You don't necessarily have to talk to the database. I mean, remember when we made our site here and just look at this contact form or even the login form. We don't have a contact or a login table in the database. So how is this working? Well, that leads me to the next part of this. See how we have this login form and contact form? Well, yes, pretty self-explanatory. You can guess which one goes where. So this is a C form model. Now, the instinctive difference between a active record and a form model is active record points to a database. Form model exists solely in the model itself using form data. Sounds confusing, I know. But really all you need to know is the C form model, the model is a representation of the data. The data exists in a form. So we have a name. This is the contact form, by the way. We have name, email, subject, body, and verify code. We have some capture codes that you can actually enable on the server side parameters. We'll talk about that much later. Got a rule set. We're just saying that these are required. Name, email, subject, body. They are required. Email is an email field. That's something we haven't seen before. What that means is you in the background will look at that email field and determine that it's actually an email address. So as you just type in 1, 2, 3, 4, it's going to pop back and say, ooh, not a valid email address. So let's actually try that. Let's say like test, test, test. Do you notice how the fields are turning green because we have data in them? If we say test, it's not a valid email address because it's actually going through an, I gotta think of a domain, blah, blah, blah, blah. Now it suddenly thinks it's an email address. Doesn't necessarily mean that domain exists. And there are actually extensions you can put into E that will test to make sure that domain exists and that even that address is valid. So that's pretty sweet. So you should just be aware of that. Now this data exists solely in the form. So when we post this, ta-da, what we've effectively done is we've created that C4 model, loaded the data from the post, and then shot it off. Attributes, we've already talked about that. Verify code is that. So let's actually look at how that contact form worked. We're gonna look at the site controller because, well, we're in the site slash contact. So we're in the site controller and we're gonna go down to contact. Ooh, a lot of code there. Look at that. We're making a new contact form, which is that model. And then we're saying if set post contact form, we're loading the post data into the model. Then we're validating the information. And you see we're doing a little bit of encoding here and that's why I really wanted to bring this up is we're at UTF-8 encoding and then base 64 encoding, the name, the subject, the headers, and we're putting it in a specific format. And then we're actually shooting it off via email. And then we're setting a flash, which we'll talk about in a future tutorial. And then we're rendering the contact with the model. Now that's important right here because if you don't re-render it and you just type in something, the minute it posts back, it's going to just blank out. There'll be nothing there. All right, now let's look at login. That's similar. It's using a login form. Let's actually go there. I think I just heard thunder. We may have to cut this video a little short. Little simpler. You just have two fields, but they're both required. Well, it's a little remember me here. Same thing. We're saying ifset, ajax, da, da, da, da. Really what we're doing here is we're validating the form by ajax. That's all you need to be aware of with that. It even says if it is ajax validation requests. So if you don't want to deal with ajax, get rid of that. Otherwise just leave it there. Just really understand that's what's validating the form. And then if the login form has been set, we're loading the attributes once again. Validating and login. That's something we're gonna cover in a future tutorial. Yee actually has a fairly robust login system. And if they're able to validate and login, then we're simply redirecting them to their return row. And then at the very end, if they haven't already been redirected, we're just redirecting them back, sorry, we're rendering the login view. Now, this is a prime example right here when we've talked about controllers before, how a controller doesn't necessarily need to render anything. For example, log out. We're actually logging out the user and redirecting when we're all, but we're not rendering anything. Well, that's all for this tutorial. Hope you found this educational entertaining and that's a broad overview of controllers.