OK, so welcome again to "Web Applications for Everybody". We're doing a bit of code walkthrough. Right now, we're on talking about the forms topic. And so, what I want to talk about is this model-view-controller pattern, but I'm start with some code that sort of I've used to before, this guess code, guess.php, where we're supposed to guess a – play a guessing game. guess=14, It's, oops, I did a minus sign there. Guess is too low. So, I want to take a look at this code. And so this is kind of a typical crude basic PHP script, a bit disorganized. It starts with some HTML 'cause that's what they are, it's a template, and it drops into PHP and then does some logic and then puts a bunch of echo statements. And what it does do well is, it's structure overall, top to bottom, is not what I like and I'll show you in a second how I want to restructure it, but it does do a pretty good job of, you know, checking to see if there's a guess parameter and complaining if there's not, checking to see if the guess is too short. This is all input validation it's doing a pretty good job of. In my next application, I'll have it better structured, but I won't do this validation. And then once I know by the time it gets to here, I know that I've got at least sane data and it's a number, it's not, it's the right length and it exists, and then I can say if it's too low or too high. And otherwise, if it's equal, then I say congratulations. So, this is nice little error checking here, a nice structure with else-ifs, I like that. But, the fact that I just sort of like intermingle my PHP with my HTML gets a little bit sort of confusing after a while. And so, and this is not either the greatest application but it demonstrates quickly and simply this notion of what I call, well, what the world calls model-view-controller and this is my really simple implementations of model-view-controller. You can go Google model-view-controller and you can, and you can, model-view-controller. and you can read so You know, I even used that slide in my talk. And the whole idea of model-view-controller is that when you're doing the request-response cycle, there are three basic things that happen. One is the data model gets updated, the database, the backend, etc. You generate a new page, and there's this thing called the controller which decides what to do with the model data, what next screen to pick, how to respond to the incoming POST data. And so, I would call it controller-model-view rather than model-view-controller, and that's kind of like the picture that Wikipedia is showing you here. And you can read and read and read and read and read more about model-view-controller, and there's whole frameworks that do model-view-controller. But what I do to keep it simple so that you know model-view-controller in kind of this low-level sense and then when you move to a framework that's more advanced then you can just use the framework to do all the model-view-controller magic. So in model v – so this is kind of like the model. And so what I do is I always start my PHP files that are gonna do data processing in PHP, not in HTML, and the model is handling the incoming data. And the view, there's always a line in every one of my scripts where you see, oh, I've switched from the model to the view, at least the ones that process data. So above the line, the idea is you talk to databases and do your data processing and handle POST data, and below the line you just mostly generate output. That doesn't mean that you don't sneak a little PHP in here because PHP is both a programming language and a templating language. And in this case, I'm just deciding if the message is not false, print it, or print out the old value in the form using the htmlentities() and the <?= for the echo. So, the idea is there's always this line above which we are completely silent and below which we don't do any major data operations. We can do loops and whatever, but we don't talk to a database, we don't do that thing, and so that's my discipline. And controller is the whole script. And if we get later in more sophisticated things, we'll see that we're doing routing decisions, we're sometimes moving – after we process the data, we send them to a different script. And so orchestration and routing is the function of controller. So, this guessing game, guess_mvc, this guess_mvc is gonna look like every other guessing game we've made. So if I say 12, now it's a POST. If you look, it's gonna be a POST, so it's not gonna show up here. So, old guess was 12, and it says too low and guess is 12. OK. And then I can change it, 123. It's too high. How about 121. So all this stuff is working. But if you look at it, what's happening is oldguess if in a GET request – so let me do a GET request by just hitting it and hitting enter, so I do a GET request. There is nothing in POST, so oldguess is false and message is false. And there is a thing that's passed between the model and the controller – the model and the view. I call that the context, and that's really, in this case, is just two variables, $oldguess and $message are set and then fall into the template, passed into the template. In other frameworks, we're more explicit about constructing a context and rendering a template with that context, but I'm keeping it really simple by saying context is what falls through from here to here. And we have to do it in a GET request because it's going to run these two lines of code and then skip all the way down to here. So, $oldguess is nothing and $message equals false, and that's why there is no guess here and there's no message. But then, when I say 12 and I hit a POST request, it is going to be, this is going to become true. And now, there's no error checking, I'm sorry. I'm trying to keep this simple so it fits on a screen. So error checking would go up here, this is actually the logic of the guessing game. I'm just converting this to an integer by adding a zero to it – that's kinda quick and dirty – and then I'm checking to see if it's 42 or less than 42. But what I'm doing is I'm not putting echo statements here, I'm setting the message and then letting it fall through into the template. So, there will be silence up here, there will be a bit of silent work that you don't even see up here where $message and $oldguess are being set right here and then it falls in and then it renders it and away you go. And so, that's the basic idea of model-view-controller and we'll talk about this a bunch especially when we have more interesting stuff to just looking at the guess. And especially when we get like two to three pages of code up here, it's important to really mentally separate the brains of your code from the look of the code. So, model at the top, view at the bottom. OK? So, I hope that has been helpful to you. See on the net.
