Advanced PHP Web Application Development

Hello again, and welcome back to Educator.com's Advanced PHP with MySQL course.0000

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

incorporating what we learned in our last lesson about exceptions.0008

In today's lesson, we are going to be going through two different versions of the web application.0013

We are going to have a version 10.0 and a version 10.1.0018

In the first version, 10.0, first, we have made a couple of changes to our admin site,0022

particularly to addItem.php and addItemToDept.php, which are two administrator pages.0031

What we are going to do is remove the old error handling process that we had before.0040

And instead, now we are going to use exceptions to manage error handling.0045

We are going to include some try/catch blocks to demonstrate how to use those try/catch blocks in a real-world application.0051

As part of that, we are also going to be creating a new admin page called error.php.0061

What is going to happen is: whenever an exception occurs on one of our admin pages (either addItem.php or addItemToDept.php),0066

it is going to catch that exception, and then what it is going to do is: the application0074

is going to redirect the user to this error.php page, which will output an error message.0078

So, first of all, let's look at our old addItem.php page.0086

The way we have done our error handling is: we have an error flag and an error message variable that we use when we encounter an error.0095

For example, if there was an error adding an item to the store, then we set the error flag to true.0104

And we say, "The data provided for the new item was invalid."0115

And then, down here, in our output section, we test to see if the error flag was set.0120

And if it was, then we skip our typical output and output the error message.0124

What we do in our new version is: in the top, we (let's take a look at it) enclosed all of our data processing section in a try/catch block.0130

So, what we do is enclose all of our data processing in a try block.0147

And what we do is: for example, in addItem.php, we create a new Item.0154

If the Item is not valid (this isValidItem is our function that tests whether the new item has been provided all the correct information--0161

whether a correct image has been uploaded, and so forth), then what we are going to do is throw an exception0171

that says, "The data provided for the item was invalid."0181

Then, when we try to insert the Item into the store, another exception can occur if there is an error with the insertItem function.0185

So, if insertItem returns false, then what we are going to do is throw an exception that says there was an error adding an item to the store.0192

Well, because we have a try block, we also have a catch block associated with that.0200

This is going to catch either of these exceptions, so if either of these exceptions occur, it is going to catch the exception.0205

And it is going to be accessible by our variable E, which we can access within the catch block.0210

And what we are doing is using the header function that, when used with the Location header, allows us to redirect the user to a new page.0216

If an error occurs, we catch the error, and then we are redirecting the user to error.php.0226

And what we do is: we are providing error.php, by a query string, a GET variable called error.0231

And we are simply providing the message that was in whatever exception was caught, and we are URL-encoding it.0238

If we look at error.php, what it does is processes a GET variable at the very beginning,0247

which it tests for the error GET variable, which is provided in our query string.0253

And then, if an error message was provided (meaning the error GET variable was provided),0259

then what we go ahead and do is output the error message, if one exists.0266

And if not, we just say an error occurs (like, for example, if somebody had just randomly gone to error.php).0272

The same thing happens for addItemToDept.php.0280

In our old version, had our error flag and our errorMsg variables that we used to report errors.0283

If there was an error adding the department, we set the error flag.0290

If there was an item ID or department ID that was invalid, we set an error.0294

And then, in our output section, we tested if an error had occurred; and if so, we output a message.0300

Well again, similarly, what we are doing in this new, updated version (version 10.0):0305

we are encapsulating our data processing section at the beginning of the file in a try block.0311

And any time an error occurs--for example, if the addition of the item to the department was not successful--0318

we are going to throw an exception that says there was an error adding the item to the department.0324

If some of the data provided on the form is invalid, meaning that, for example, the item or the department ID provided is not a valid ID,0330

then we are going to throw an exception that says the data provided on the form is invalid.0338

Again, we have an associated catch block, and it is going to catch an exception.0343

And it is going to associate it with the variable here; again, we have chosen E.0350

And again, we are going to redirect the user to error.php and simply provide, via the GET variable error...0355

we are going to set the GET variable error equal to the message encapsulated in our Exception object.0363

It is going to forward it to the error page, and the error page is going to have the same output.0369

If we go and take a look at our Educator store, and we look at the admin website, here is our addItem page.0373

And let's say we try to add a new item, but...let's provide an image...let's say we don't provide a description.0381

And as we know from working in our web application before, all of these are required fields.0395

So, what is going to happen is: when addItem is processed, it is going to test all of these data fields in the isValidItem function.0400

What is going to happen is: it is going to return false, because we didn't provide a description.0411

So, this exception is going to get thrown that says the data provided for the new item was invalid.0415

The exception will get caught, and we are going to get redirected to error.php.0420

When we go ahead and click Add Item, it is going to direct us, if you look at the browser at the top, to error.php.0424

I'm not sure if you will be able to see the text big enough.0434

You can see that the error message was appended as a query string.0435

And we have set the error GET variable equal to a message that says the data provided for the new item was invalid.0441

And then, you can see here that our page goes ahead and accesses that exception message and outputs it on the page.0448

And the same thing works for addItemToDept, when, for example, an error occurs in adding the item to the department.0455

The other thing that we have done is: we have also added, in our DataFile class, an open method,0467

which is used to open the particular data file (for example, items.txt, departments.txt, or lastAdded.txt).0473

And when we open the file, a file open error might occur.0481

And if that occurs, then it is a fatal error, in a way, in that our application is not going to work.0484

What we are going to do to handle that: whereas before, what we did in our previous version of the application0491

is just to directly output an error that says, "There was an error opening the file";0496

now, what we are going to do is use exceptions to handle that error.0501

So, what we do is: we are updating our open method so that, rather than outputting an error message, it is going to throw an exception.0507

Then, whatever method calls our open method is going to surround the call with a try/catch block,0515

so that it can catch that exception that occurs if there is an error opening the file.0524

For example, if we go and look at our documentation for (let's blow this up a little bit) DataFile,0529

and if we look at the open method, we can see that what we have done...0543

And actually, let's go ahead and open up the old version, as well.0548

If we look at the open method in our old version, if there is an error opening the file, we output an error message0564

that says, "There was an error opening the data file," and we simply output that to standard output, which is going to be output to the user.0572

Well, instead, in our new version, what we do is: when an error has occurred, we throw an exception.0578

And what happens when that occurs is that the execution of that function stops,0591

and whatever method called this open method is going to have to handle, or catch, this exception.0594

So, here we have, for example: if the fileHandle property was null (meaning that an invalid file name was provided0601

in the constructor to this DataFile class), it is going to say (formatting is a little messed up here)0610

that there was an error opening the particular file.0617

And then, what that is going to do is throw an exception if there was an error in the call to fopen in the file.0622

Down here, it throws an exception if the filename property was not properly set, meaning that you provided an invalid filename to the file.0633

So then, what happens is: for example, all of our functions in our file library0643

that use the GET open method now are going to enclose things in try/catch blocks.0648

For example, in our getItem function, which loads an item from the database, what we do is:0654

we declare a new DataFile object, and then we try to open the file.0661

And what we have done now is enclosed that in a try block.0667

And what happens is: we catch the exception, and then, right now, we are simply returning false.0672

We are not outputting any error message, which is different from our last version, in which what we did is:0676

when we called the open method, we enclosed it as a test for our if statement, because open will return true or false.0693

And if it returns false, then we can say, "OK, we are going to return false from the method."0702

What we have done in our new version now is used a try/catch block instead.0707

So, rather than enclosing this in between the if's parentheses, we simply...if it doesn't throw an exception,0711

it is going to continue executing the code in the rest of the function.0721

If an error is thrown, then it is going to know that an error was thrown, and it is going to return false.0725

And we are going to see, in the next version of our application, that we are going to show a way to log that error,0731

so that we can find out information about it.0737

Right now, all that happens is: when a user tries to get an item (for example, when you go to item.php0739

and it tries to load the item from the database), if there is an error (opening the items.txt file, for example),0745

all this method is going to do is return false, and it is not going to allow you to load the item.0753

But it doesn't really provide any information to the user.0758

Before, in our old DataFile class, we had, in the open method, output an error message, stating that you couldn't open the file.0760

But that doesn't look very good if that happens--if it just outputs a random error message to the user.0778

So, what we are going to do is: we are not going to output an error message in our next version of this web application.0783

We are going to show you how to log that message, so that it handles the error gracefully.0787

It doesn't show an ugly error message to the user, yet you still see that the error occurred.0792

All of our functions that use that open method (for example, getDepartments) all enclose the call to the open method within a try block.0798

And then, they catch any exception, if it occurs.0810

What we have done, in a new version of 10.1, is added a little bit of a feature to our web application that involves what is known as a logger.0819

And there are libraries out there that you can use that are logging libraries, that allow you to insert statements in your code0828

that allow you to log errors or warnings or debug statements that help enable you to debug your code.0837

We have created, for this, a simple Logger class; it is a new class.0844

It makes use of our DataFile class; and what it does is opens a log file, and it has a couple of static methods in it0849

(for example, logError and logWarning) that, when you call these static methods, as a parameter you pass some message.0860

And then, what the Logger class will do: it will add that message to a log file.0869

For example, we have a file open error; because we are not outputting that message to the user anymore,0875

we can log it to this log file, and then when we have a problem with our web application,0879

we can look at the log file, and it will provide information as to where things went wrong.0883

As part of this, we have updated config.php with some log-related constants.0889

If we look at config.php, we can see that we have added a LOG_DIR constant.0893

What we have done is just added a directory called logs to our web root for this particular version of the web app.0900

And then, we have also created a constant called LOG_FILE, which is the name that we want to use for our log file.0908

In this case, we are going to call it log.txt, and it is going to be stored in this LOG_DIR directory.0916

If we go and look at this new class, Logger...let's go look at the source code for it...0922

we can see that it has two static methods: it has one called logError and one called log.0934

And what it does is: when you call the logError function, it takes whatever message you pass to it,0948

appends a statement that says "this is an error," and then calls another static method that is part of this class,0959

which actually goes through the process of opening a data file, which is going to be the log file.0965

It is going to open the file and append the message to it.0972

One thing that it also does is adds a date/time stamp to the beginning of the message.0975

So, when it logs it, it is going to have a date/time stamp.0980

It is going to say 'error,' and then it is going to have whatever message you include in there.0983

So now, what is going to happen is: whenever we throw an exception (for example, we throw an exception0987

when we try to open items.txt using our open method of the DataFile class), whatever method0995

(for example, maybe in our file library, the getItem method) is going to try to open the items DataFile...1002

when it throws an exception, now what it does is: when it catches the exception, instead of just returning false,1011

it is going to make a static call to this logError function that passes it the message contained in the exception.1017

For example, in this case, because we are trying to open items.txt, if there is an error opening that file,1028

the exception that is thrown is going to say, "There was an error opening items.txt."1034

Here, we are appending a little information to it that is stating that this error occurred, also, in the getItem method of fileLIB.php.1040

Then, we call the logError method, which is going to call logError, which is going to append an error message to it.1049

And then, it is going to go ahead and write it to our data file.1059

For example, if we take a look at our website (blow it up a little bit), this is our Educator Store version 10.1.1062

We can see that it works as normal, if we look at our homepage.1077

When our homepage is loaded here, it is loading information about all of the different departments,1081

in order to output, for example, this left navigation bar.1086

It accesses departments.txt.1089

Well, let's say that we were to go and rename our file for this version departments.txt and call it departments.txt2.1093

Now, what is going to happen is: when this page loads, it is going to call the getDepartments function,1102

which is going to create a DataFile object, and it is going to call the open method on that DataFile object.1110

It is going to try to open departments.txt; it is not going to be able to.1117

So, what it is going to do is throw an exception.1120

The getDepartments method will then catch that exception; and if we look at our getDepartments method,1122

we can see that now, when it catches that exception, it logs the error to our log file.1129

So, if we go ahead and try to do this (now that we have renamed our file, and we refreshed the page),1135

here we can see that we get an error, so we know that an error occurred and that we can handle this a little more gracefully.1140

But the main purpose of doing this is to show the use of our log file.1144

What we can do is: if we look at version 10.1, there is a logs directory; there is a logs.txt file;1149

and if we go and look at it now, we can see a date/time stamp that says, "An error occurred at the 20^th hour,1156

57 minutes, 37 seconds of the 2^nd of September."1167

It is going to say, "An error occurred in the getDepartments method of fileLIB.php."1172

It is going to also say that the error occurred before that--it occurred in the open method of DataFile.php.1178

And then, here is the message that was contained in our exception that we threw.1185

"There was an error opening file," and if we look at this, "departments.txt."1188

And the reason that this shows up twice is because, on our homepage, we call that getDepartments method twice,1194

and we try to output the different departments here, as well as within our left-hand navigation bar.1200

And so, that is how our logger file works; and what it does is allows us to provide some information1206

that doesn't get sent to the user, but that we can look at our log file and debug things.1212

Also, what we have done is...for the close method of our DataFile class, that can generate an error as well,1218

if there is an error with closing the file that we have open.1225

However, because we have already extracted what information we need from the file, it is not necessarily a fatal error.1228

So, we are going to log it; in this case, we are going to log it as a warning, using the logWarning method,1235

which is also part of the Logger class, which appends a warning message to it.1240

And if we go and look at our Logger class, we can see that we have a logWarning function1247

that does the same thing as logError, except it allows us to...it appends a warning to whatever warning message we pass.1272

So, if we go and look at our DataFile class in the close method, whereas before we just had an echo statement1282

that would echo, "There was an error closing the file," now what we do is call our Logger.1297

And we have a log warning that says, "There was an error closing so-and-so file," or whatever.1301

And so, that way, we can at least look at our log file and find out if there was an error closing the file.1307

And that is a way to keep track of things.1312

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