Introduction to PHP Web Application Development

Hello again, and welcome back to Educator.com's Introduction to PHP course.0000

In today's lesson, we are going to be continuing development of our web application,0004

incorporating some of the concepts we have learned in our last few lessons.0008

First, we are going to start off by reviewing what our last version of the web app looked like, which was version 6.2.0014

And then, we are going to go through 2 revisions in this lesson: we are going to upgrade to a version 7.0 and a version 7.1.0020

Now, in version 7.2, one of the things I want to note is that we don't actually do any GET data validation.0028

So, for example, on checkout.php, item.php, and thankYou.php, all of those scripts accept GET parameters.0037

And what they do is: they access the data in those GET parameters, without really checking to see if they are available.0048

As a result, if you go directly to any of those pages, you get a warning from PHP saying you're trying to access a GET variable that doesn't exist.0054

And in addition, the page doesn't work as it is supposed to.0062

For example, if we go and look at version 6.2--and here is what it looks like if we go to store.php (let's decrease it a little bit)--0065

but if we were to go, for example, directly to checkout.php, you get an error at the beginning saying "undefined index items."0082

That is because we are trying to access, in our code, the items array.0089

And, for example, if we go directly to items.php, we are going to get an error, as well.0094

And if you will notice, none of the item information actually shows up down here on the screen,0101

saying that you are trying to access an item ID that wasn't provided.0106

And if we go and look at the code, for example, for this page (this is the 6.2 version of item.php),0110

we can see the second statement in our code--we create a variable called currentItemID, and we set it equal to _GET['itemID'].0118

Now, instantly, because if we go to item.php without providing an itemID GET variable, this is going to generate an error,0130

because this variable doesn't exist, because it wasn't passed in.0137

And, in addition, because we use this currentItemID variable in different parts of our page to look up item information from the catalog,0141

none of that is going to work, as well.0148

So, it has the implications of generating an error, as well as not allowing the script to function as it should.0150

What we are going to do is: in version 7.0, we are going to make use of if/else statements that we learned about.0160

We are going to use the isset construct that we have learned about.0165

What we are going to do is some basic validation on our GET variables.0170

What we are going to do is: we are going to test that any GET variables that are required by a particular script0173

(in this case, checkout.php, item.php, and thankYou.php)--we are going to verify that those variables actually exist and were passed in.0178

We are going to do that using the isset function.0189

And if they are not set, we are going to set them to null, by default.0192

Then, what we are going to do is: when we do this process of checking to see if they are available,0196

we are going to create short forms of these GET variables, which is something that you commonly do in PHP,0202

because it's a lot easier to write, for example, dollar sign, item ID, than dollar sign, underscore, GET, square brackets, item ID.0207

So, it is a way to make it easier to use the variables within your code, without clouding it up with unnecessary syntax.0216

We are going to create these short variables when we validate them, and then we are going to0224

use them to conditionally output the HTML content of the page.0227

And what that means is: if the appropriate GET variables were provided, we are going to output the content of the page, as we are supposed to.0233

If not, we are going to output an error message.0241

And one thing in particular we are going to do is: we are going to make use of our logical AND operator,0244

which we learned about, in the validation of our GET data for thankYou.php.0249

We are also going to divide each of these three pages into different sections, and we are going to use comments to do that.0256

What that is going to do is separate out functionality of the page, and it makes the pages easier to understand.0262

When you go back and look at the pages, you will know, "OK, the top of the page is where the GET variables are always processed."0267

"At the bottom of the page is where the HTML output always occurs."0272

Let's go take a look, first, at item.php; and this was the old item.php; and let's see what it looks like in an updated version.0276

At the top of the page, we have added a new section; and the way I have demarcated a section0286

is just by adding this comment tag that says "process GET variables."0292

And what that is going to do is: this section is going to be used to create the short variables for our GET variables,0296

and also to check to make sure that they are valid.0303

So, for example, we have our if/else statement, which we just learned about a few lessons ago.0306

And we run the isset function on _GET['itemID'].0311

And if _GET['itemID'] exists and it's set, then we set currentItemID to that value; if not, we set it equal to null.0315

Then, what we go ahead and do is: in a previous section, if you look at our old itemID, after we have made0324

a short version of our GET variable, we did a little processing on it.0330

For example, we look up the current item in the item catalog; we set the page title for the page.0333

Well, I've created a section called Perform Any 'Global' Data Processing; in this section...0339

these sort of actions that occur after the short GET variables are created--this section will contain them.0344

And you can see, there is another if/else statement in here, and it is going to make use of the fact0352

that we have created the short variables, and we have validated whether or not they are actually input.0357

For example, to avoid that error that we got on previous pages, what we have done is checked to see0361

if currentID was not equal to the null, because if the ID was set to null, that means that it wasn't passed in.0369

And if it was, then we go ahead and look up the item in a catalog (and actually, this line shouldn't even be here),0376

because we have done that up here--we have created the short variable up here, at the top of the page.0383

And so, what this tests is if the current ID isn't equal to null, that means it was passed in, and it is set to the value itemID that was passed in.0387

And then, we can look up our item in the catalog, and we can set the name.0395

However, if this statement evaluates to false, which means that it was null, which means that an ID was not passed in,0398

then we are going to set the page title to say error.0405

Down here, we have created a section called Output HTML, and this is where all of the HTML is going to be conditionally output from now on.0409

That is going to be based on this data processing that occurred at the top of the page.0418

For example, now, whereas before we just would output the HTML header in our old version,0422

and then go straight ahead and output all of the information about the item,0428

we have a conditional statement, an if statement, that says "if current itemID is not equal to null," which again,0433

references the fact that it was passed in, "then we go ahead and output all of the item's information."0437

But we add an else statement at the end, so if itemID is equal to null, which means it wasn't passed in,0444

then we output an error message that says "you have reached this page in error."0449

If we go and look at...again, this is what item.php looks like on version 6.2, you get these errors, and that is because we haven't provided a query string.0453

For example, if we went ahead and provided...then we get the functionality as expected.0465

Well, let's go back and look at the new version, 7.0.0473

And now, when we go directly to item.php, we actually get an error message.0478

And that is because it is processing the GET variable and saying,0482

"OK, you didn't actually present a GET variable called itemID, so we are going to generate an error."0486

Now, we have also done this for the other pages in the website, for the other pages that take GET variables--for example, checkout.php.0492

If we go to checkout.php without any GET variables, we get the same message, "you have reached this page in error."0500

And if we manually go to thankYou.php, we are going to get a "reached this page in error," as well.0506

If we go back and look at the code--let's look at the code for checkout.php, for example--0515

you can see, we have added this section again, up here at the top, about processing the GET variables.0522

We performed a similar isset test on the GET variable items to make sure it was passed in,0526

and if not, we set our short variable, cartItems, equal to null.0532

Then, if we go down here to do our data processing--in this case, because the checkout script actually calculates the total,0537

if our cartItems is not equal to null (which means that a valid GET variable was passed in), then we go ahead0546

and do the calculations, because if we didn't have a valid GET variable, there is no reason to try and calculate them.0551

And then, we have the else statement that says, "If the cartItems is equal to null," if it wasn't passed in, "then we are going to output an error page."0557

Down here, we have the HTML Output section, and again, we have an if statement that tests0566

whether or not the short GET variable exists, meaning that it was passed in.0571

If it does exist, we go ahead and output the shopping cart total that was calculated in the processing section,0576

and the form that accepts information about the customer's shipping and billing address.0582

Now, if there was an error, meaning that the GET variable was not passed in, then instead, we would output an error message,0589

which you just saw, which is "you have reached this page in error."0596

Now, in thankYou.php, we have the same similar concept, except that in thankYou.php, there are two GET variables that we access.0599

We access the variable customer and _GET ['orderTotal'], and actually, I can see here that it is supposed to have this in here.0612

What this does is: this checks that the customer GET variable was set, and (and this is where0630

we are making use of the AND logical operator) that the orderTotal was set,0640

because we want to make sure, before we access these variables further down in the script, that they are available.0647

And if not, we set them equal to null.0653

Here, we have created the short form of the variables.0655

And then, down here, in the data processing section, we have our logical operator again, AND.0660

It is saying, "If both customer data is not equal to null, AND order total is not equal to null, then0665

we are going to go ahead and set the page title to thankYou, and that is going to mean that we are going to process the page as normal."0672

If either of these were equal to null, we are going to generate an error, and here we set the page title equal to error.0679

Then, we have the Output HTML section; again, we have the conditional test to decide whether to output0685

the regular HTML of the page, the regular HTML content, or an error message.0692

And the test we have, again, is if either of the GET variables...if both of them were not equal to null, meaning they both existed,0697

then we are going to go ahead and output our order information, like we have done before,0705

where we output the date of the order, the sales tax that was used, the order total, and so forth.0708

And then, also, we echo the address.0715

And if not, we have the else statement down here that says "you have reached this page in error."0717

And so, that was what we saw when we looked at these pages in the browser.0723

For example, again, if we refresh thankYou.php, we get an error, whereas let's say we go through the application as we are supposed to--0727

and go to Complete Order: now, our thankYou page was output as appropriate,0749

because you can see, at the top here, we have the appropriate GET variables that were passed in from the form.0753

And this is the page we had developed in the last lesson.0758

So now, we are going to change things a little bit: we are going to upgrade to version 7.1.0764

And what we are going to do in this lesson is make a couple of simple changes.0769

We are going to replace the if/else statements we used to process the GET variables at the top of the page.0772

And we are going to replace them with simpler and cleaner-looking ternary operations.0778

I'm going to show you that in a second.0782

Additionally, we are going to add the error reporting function to our config.php file,0784

which, as you know, is the configuration file that we include in all of our pages on the website.0789

What that is going to allow us to do is: because we are developing, we can go into that config.php file0794

and override the global error reporting settings that our PHP configuration has set up.0800

That will give us flexibility, while we are developing, to experiment with different error levels.0807

And also, it does it in an easy way, because we don't have to edit php.ini, and we don't have to restart Apache.0811

So, in this one, we are actually going to be editing the config.php to make that change, to add the error reporting.0818

And then, in these three here, we are going to be updating the way that the GET variables are processed to use ternary operators.0823

Version 7.1 is going to look the same as version 7.0, and if we go to the thankYou page or checkout page--0838

go to any of these pages directly, we get the error, as we are supposed to.0848

However (let's see--let's pull up another...), this is an old version--the 7.0 version of thankYou.php, and if we go ahead0851

and open up the 7.1 version, at the beginning of thankYou.php in 7.0, when we process the GET variables,0862

we have this if/else statement up here, and it's saying that if these variables are set,0873

then go ahead and set their value to the value that was passed in; if not, set that to null.0877

We can do that a little bit more simply using ternary operations.0881

Instead of that if/else block, we can set customer data, and we set it equal to the customer value that was passed in,0886

if isset ($_GET ['customer']) is true (that means if it was passed in), we set it to the value; and if not, we set it equal to null.0896

Likewise, for orderTotal, if the order total was set, if it was passed in, we set the value of the short variable orderTotal0902

equal to the value that was passed in; and if not, we set it equal to null.0910

As you can see, this cleans things up a little bit, and makes things a little bit easier to read, and it's a pretty simple operation.0913

That is how we use the ternary operators; we do that on item.php and checkout.php, as well,0921

where we have replaced the if/else statement at the top with a ternary operation in0931

checkout.php--for the cartItems short variable and for currentItemID in item.php.0935

So, as mentioned, the other change that we made is: we added, at the bottom (this is the top)--0943

if we go all the way down to the bottom of config.php, we have added a section for error reporting,0948

and we have added this error reporting function, which, as we know, overrides the default PHP configuration's error reporting level.0952

And in this case, we are going to set it to development value E_ALL OR E_STRICT,0962

which means output all error messages, and then also, in addition, any notices that fall under the E_STRICT category.0967

This is the value that is set by default in the XAMPP php.ini file.0975

What we are going to do, to make this error reporting function do something useful,0981

is go ahead and edit our php.ini file to make it more restrictive, to put it on, for example, a production value.0985

Or, in this case, we are going to set it to the default value, which says "I want to report all errors, except for the notices--except for E_NOTICE."0995

And that is different from E_ALL or E_STRICT, because in the E_ALL or E_STRICT, the notices get output.1005

So, in this case, when we set this global file like this, and we go ahead and restart Apache,1013

it is going to have this new error level that is going to report less errors.1021

And so, now, when we go to our config.php file, because this is included in every page, it gets set back to this development level.1026

Now, in the real world, you may or may not do this; you may actually just go ahead and edit the php.ini configuration file.1037

The point why I'm putting that in here is to get practice with using this error reporting method,1043

and to see how it can be used, because maybe sometimes you won't have access to the php.ini file on whatever server you are working on.1048

And so, this will allow you to be able to do that.1056

And so, that is how we make use of the error reporting function.1059

For today's homework challenge, I just, as usual with our web application lessons, want to make sure that you understand the different things.1063

So, the first thing is to make sure that you understand why we added the simple GET input validation to our scripts.1071

And that was because that way, we don't get any warnings from PHP saying we are trying to access data that doesn't exist.1077

And also, it causes our scripts to not malfunction--like, for example, the item.php page that tried to access data that didn't exist.1083

And you could see, there were blank images; it didn't output the price; and so forth.1093

And we made use of the if/else statement within our item.php page to only output the item's information1097

if we know that an item ID was properly passed in; otherwise, we output an error.1105

Also, I just want you to consider how dividing the page into different sections--and this will probably become a little more evident1109

as we move on to future versions of the web application--based on functionality makes it a little bit easier to understand.1116

When you go to the file now, you always know that, in the current setup, the bottom section is going to always be where the HTML output occurs.1125

So, you know that, if you are going to be looking for any HTML output (maybe you have an HTML output area),1133

you are going to be looking down at the bottom.1137

We know, at the beginning, there is the section where we process and create our short GET variables.1139

And then, there is a section where we do data processing; and what that is doing is preparing the data for output in the HTML.1144

So, if maybe some of our data is bad, then we can know to go look in the Data Processing section.1150

That just makes things a little bit easier to maintain and debug, and aids other people that could end up reading your files, as well.1154

That ends today's lesson; thank you for watching Educator.com--I look forward to seeing you next time.1162