So now I want to talk about a pattern, a programming pattern that we call Model-View-Controller. This is something that if you're going to be a web application developer, you might as well just be able to like being part of a conversation about Model-View-Controller, so you should just know this because you're like, "I'm MVC, you're MVC. My MVC is better than your MVC." That's the way how we talk. MVC stands for Model-View-Controller. What it really does is it breaks the request response cycle at least how we can handle it into three basic operations and it's helpful to have this terminology so I can say, "Oh, that's the model. That's the view and this other things the controller." The basic definition in a pure sense is that we take data, we might update the model, and the model's the permanent storage. The controller is this thing that decides when to do things and when to switch from one screen to another. We'll start seeing that more later. Then, the view is the next thing that you see. You could think of it as, it comes into the controller, the controller updates the model, the model then is done, maybe when you read the data which is reading from the model, we produce a view and then the user is involved. This notion of there is sort of you know Model-View-Controller, it should be see called Controller-Model- View but that doesn't roll off the tongue as well as Model-View-Controllers, so MVC. There turns out to be lots and lots of different ways inside of code and if you're familiar with, or if you've heard of things like CakePHP or Angular, or React, or Symphony, these are all ways of interpreting the Model-View-Controller differently. What I'm going to show you is one way of interpreting the Model-View-Controller. This is the way I'm going to teach you and what you'll probably find out is mine is very simple because it's all in one file and it's very PHP-like. It's very sort of first principles, but ultimately, if you look in a framework they will put sort of the Model stuff in one file, the Controller stuff in another file, and the View stuff in the third file and then they'll knit those things ToGETher. When you learn that, there's no right or wrong. They are are just patterns that help organize things and so if you're going to use, do a Symphony App and you've done a bunch of Symphony Apps you know where all the models are at, you know where all the views are at, you know where all controllers are at. What I'm doing is something that's kind of a more low level than that and putting it all in one file. What we do, what I do is I basically make it so that when I'm writing a code I break my code into two parts and what I do is in the top part I do all the model parts, so the models the top part meaning that if there is incoming data I handle it. Sometimes there is no incoming data and I go straight to the view. Sometimes there is model. Then I always can draw a line between the model code, this is also silent and I mean by silent there is no output, right? There's no output whatsoever. It's the silent part of the you're handling input data. Again, there may be no data so you skip right past it, and then you fall into the views. The bottom part is the view and it produces the output and basically, there's some rules about what you're not supposed to do down here. You're supposed to pass some information down and you're not supposed to talk to the database down here. You're supposed to talk to database up here because when you're talking to the database you're working with the model, okay? This is what it looks like, right? In this case, I'm refactoring that guessing game a little bit where I have the old guess and the message. These are the pieces of data that are going to be in the view and so if you come down here you will see that I'm going to print out the old guess and then print out the message. I'm going to start by saying the old guess is nothing and the message is false and if I have some data, I'm going to handle that data and I could put better validation in here but I've didn't do that because it wouldn't fit on a screen so I'm just going to check to see if it's 42, less than 42 or greater than 42. Instead of printing it out in that if, I'm actually going to just have this variable message fall through into the view and the data that we send between the model and the view is called the context. The view has little bits that are to be replaced with data, it's not just static HTML. It's dynamically generated HTML and the context is that set of things that were sort of passing between the model and the view and the controllers making all these decisions. Later, we'll do these more complex things and these are route to other files and that's another controller activity. Deciding at when to do stuff, what to do with the model, deciding when to switch to the view, that's all the controller, and when to switch to completely different files, that's all controller stuff, okay? A simple rule to follow is that you're not supposed to generate any HTML on the top part and you're not supposed to touch the database in the bottom part. Any database stuff is supposed to be done before we cross this line and passed in as a variable into the view, okay? That's just a discipline thing. It doesn't mean we can't do it if_statement remove_, isset() adding(). It just means that we're going to be disciplined and we're going to follow this Model-View-Controller pattern and so if you look at my code and I look at your code, we can follow the same convention. Like I said, this model part is in the top and again there's always this line that you can draw. We're going to pass the context which is going to just be two variables old guess and message, sometimes context is much more complex, we have an if_statement and there's always an isset here and it's always looking at POST. The first thing is deciding is, is there any input data at all and if it's a GET request cause are coming in the top wants to GET request, to show the page and then when the submit button is we're coming back in again as a POST request, okay? In the GET request, this is false, in the GET request it's false, actually let me do it this way, right? We come in once with a GET request and a second time, we come in with POST request, right? When the GET request happens, it's going to set this to negative and then it's going to skip all this it's just going to fall through, right? There's no POST data, but if we then have POST, it's going to set this but then this is going to be true and then we're going to set message to be something different and then we're still going to fall through so both to GET we come at the top, for both GET and POST and we exit at the bottom for both GET and POST but we've got a different context. Context are these two variables that are passing between and across the magic line and if we take a bigger look at what's going on below the magic line, right? This is the magic line. The model is above, the views below and the context is coming through. The context are these two variables, so we come in here and we have to know that this view code is going to run two different ways. We have to put some if_code in it. We're say you know if_ there's something in the message, message false means there's no message to show but if there is, then we'll print it. So this is going to show up on the POST but not on the GET because message is going to be false on a GET request, continuing through with this HTML. Anyway, use those shortcut and of course we use HTML entities. I'm very proud of us because we're using HTMLentities() , of the old guess. Now remember, if this is a GET request old guess is an empty string and if it's not, it's 42 or whatever the old guess was. That's how our view constructs itself from the context that's passed in. This is just a slightly more verbose way of doing exactly what we did before with kind of our Model-View and Controller are all mixed into one file, but this discipline, as our code get's more complex, having a discipline that puts certain things here and rules about what we do up here and rules about what we do down there. It's really helpful, okay? In summary, we talked about the Superglobals GET and POST. We talked about when you might use them, we talked about form fields. We talked about these like colors and dates, and all the validation that we can put in. We cover a lot of stuff in this lecture. How do you see similarities, to sanitize the HTML so you don't end up with HTML and an injection, some of the functions and techniques that you can do to do data validation when data is coming in to your server, and kind of a way to structure our server code, using the Model-View-Controller pattern knowing that there are many ways to do this, many frameworks, many languages. But we're going to start with something that's sort of very pure PHP and then we'll learn more about those other evolutions on Model-View-Controller later.
