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 properly destroying a session.0009

Specifically, we are going to be introducing one new topic, called the __autoload function, which is a special function in PHP0014

that is going to make it easier to load class definition files and eliminate some include statements from our config.php file.0021

And then, we are going to go over version 13.0 of the web application, which is the new version of our web application,0029

which is going to incorporate what we learned in the last lesson about how to properly destroy a session,0035

which includes deleting the session data explicitly, and then also deleting the session cookie.0040

First, one thing to note is that, as your web application grows, and you add classes to it,0047

you are going to have an increasing number of include statements--for example, in our application in our config.php file,0053

in order to include all of the class definitions that you have; and that can become tedious after a while.0061

And in fact, if we go and look at our config.php file for the last version of the web application,0066

we can see that we have all of these includes here for all of the different classes that we have created.0077

So, as we add more and more classes, we are going to have more and more include files.0082

And it can become cumbersome, and it would be a nice way to automate that.0086

What PHP allows you to do is create a function that starts with two underscores, called __autoload.0089

And if you define that in a file somewhere in your application, and include the definition of that function,0099

PHP is going to use that file to automatically load a class.0105

So, whenever it reaches a point in your code where it is instantiating a new instance of a class,0108

what it is going to do is call the __autoload function.0116

It is going to pass it the parameter that this __autoload function takes, which is the name of the class that it is trying to load.0119

For example, if it comes upon a statement "item variable equals new Item"--let's say we are creating a new Item object--0126

what PHP is going to do is call the __autoload function automatically with the name of the class, Item.0138

And then, what we do is define this __autoload function so that it knows how to take this name0149

that was passed to the function, and be able to appropriately load that class.0155

That way, we can get rid of all those include statements, and instead we just have this one __autoload function.0161

If we take a look at the __autoload function that we have created for this new version of the web application,0166

it is stored in a new library file called classLIB.php, which contains functions related to classes.0172

In this case, it is just one particular function.0179

And here, you can see that we have defined the __autoload function.0182

And what it does is: it takes one parameter, which is a string, which is the name of a class to load.0186

And then, what it does is: we have coded it so that it calls an include statement to include the class definition file that PHP is requesting.0193

And the reason we define this function is because we know where our class is located.0206

In this case, they are loaded in the class directory that is specified by our CLASS_DIR constant.0212

In addition, the names of our class files are the name of the class, followed by .php.0217

So, maybe somebody else's application might have a different way of naming classes.0223

For example, some people call their classes item.class.php.0227

So, this would be the spot where you would be able to adjust your code so that PHP is going to be able to properly load these classes.0233

Again, this function is just your way of telling PHP how to find these classes and load them.0240

We have added the __autoload function, as mentioned, to this class library that we now include as part of our web application.0247

And in addition, if we look at our new version of config.php, and we look at the source code,0256

in the last version (this was version 12.0), we have all of these include statements for all of these different classes:0268

Cart, CartItem, Customer, Department, and so forth.0274

Well, in our new config.php file, we have eliminated all of these include statements for all of these different classes.0278

And instead, we have one include statement that includes our classLIB.php that defines that __autoload function.0285

So now, instead of having to list all of these different class includes, we just include the function definition for __autoload.0291

The other nice thing about that is: if we don't automatically...we include this config.php file on every page in our web application;0297

so, every time we load a page, it goes and loads all of those classes that we had listed in our previous version.0304

Because we have an include statement before it, it automatically goes and gets that class definition file and loads it.0312

It is going to load all of the classes; it may be, on our page, we only need a Department class or an Item class.0316

It is going to go ahead and load all of those other class definitions that it doesn't necessarily need on that page.0323

The nice thing about this __autoload function is that it is going to reduce some of that overhead,0329

because you are not going to be including files you don't need, because __autoload will only be called when a particular class file is needed.0333

The other thing that we have done is created a new class called SessionManager,0341

which is part of the reason for introducing this __autoload function now,0346

because the number of classes is continuing to grow in our application.0350

This SessionManager class has been created to handle all of our session-related tasks.0354

For example, starting a session, adding variables to a session, and then now0362

what we are going to learn about in today's lesson, destroying a session--are all combined to this one class.0367

If we go and look at our SessionManager class, and look at the documentation for it,0373

we can see that it has a couple of different methods.0385

It has a constructor; it has a destroy method, a getVar and setVar method (which are methods used to add a variable to a session),0387

and then an inSession method, which is a way of being able to test whether a particular variable is currently set in your session.0395

If we look at the constructor...0403

The way we use this class is: in any script where we want to access sessions, we instantiate an instance of this SessionManager class.0405

Now, when the constructor gets called, it automatically calls this session_start method.0415

So, just by instantiating that class, we have gone ahead and started a session.0419

And then, we can do things, for example, like call the setVar method; and we could pass it a name and a value.0423

And what that does is goes ahead and accesses our _SESSION superglobal, which is now accessible,0430

because once this object has been created, session_start has been called, and it allows us to add variables to the session data.0435

It has a getVar method, which is the analog of the setVar method, which returns the value of a particular variable.0443

We specify as a parameter the name of the session variable we are trying to get.0453

And here, what it does is: it returns null if that session variable doesn't exist, and it returns the value of that session variable if it does exist.0457

The way it does that is makes use of this inSession function, which is also defined in this class,0467

that just tests if a variable exists in the current session or not.0472

And it does that in the same way that we did before.0476

For example, in some of our homework and lecture examples, we use the isset method to test for the existence of a username session variable.0479

By testing, we use that as our way of saying, "OK, a user has been logged in."0487

This provides that same sort of functionality: we provide the name of the session variable to inSession that we want to see if it exists.0492

And it returns the value of the isset method.0498

Now, the one nice thing about having this class to manage all of the session-related functionality0502

is that, if we have any problems with our _SESSION superglobal, or we are having problems with our sessions,0508

we only have to look in one spot, because anything related to sessions is all handled in this class.0515

Instead of having, for example, in our previous version of the web application, a session_start method call,0520

and then accesses to the _SESSION superglobal, and then also directly setting session variables0528

and having them spread throughout all different versions of the code,0536

we can put it all in this one class, and then we call these class methods.0539

And so, if we have a problem with accessing, for example, a session variable, we only have to look in the one spot, which is our SessionManager class.0543

Now, one of the main reasons that we have added this SessionManager class is because it has a method called destroy,0551

which is going (now that we have learned in our last lesson how to properly destroy a session) to succeed in doing that.0558

And I am going to go ahead and open the source code for it, because it calls a private method, which doesn't show up in the documentation.0565

We have our destroy method, which, when you call it on a SessionManager object--the first thing it does0574

is deletes any session variables, and does so by setting the _SESSION superglobal equal to an empty array.0581

It destroys the session cookie (which--we learned that just by calling session_destroy, that doesn't happen).0594

So, we have an explicit method that destroys that session cookie, which I am going to show in a second.0599

And then, to ensure that the session data stored on the server is destroyed, we call the session_destroy method.0604

The four steps that we learned about to destroy a session (calling session_start, deleting the session data,0612

deleting the session cookie, and calling session_destroy) all happen in this one class.0618

When the class is instantiated, that calls the session_start method, which is step 1.0623

And then, this destroy method completes the other three steps.0627

If we look, we have a private method here called destroySessionCookie, which is used to destroy the session cookie.0630

And it performs the functionality that we saw in the last lesson.0636

It gets the parameters of the session cookie for the current session; it retrieves the name of that session cookie;0640

and what it does is calls the setCookie function that sets that session cookie to expire at a time in the past.0646

When this destroy method is called, it calls destroySessionCookie, which calls the setCookie function.0655

So, when the user gets their HTTP response back for this page, the user is going to know0661

that the cookie is expired, and therefore the session is going to be officially ended, and it will be properly destroyed.0665

That is what we use this new SessionManager class for.0672

What we have done is updated our viewCart.php and checkout.php scripts, which are scripts that use session functionality.0678

And we have updated them to use this new SessionManager class for all session-related tasks--0688

For example, starting a session with session_start, and then loading and saving our Cart object to and from the session data.0693

If we go and look at our old viewCart script, for example, we have an explicit call to session_start.0705

And the way we load our cart is by calling the isset method on the _SESSION superglobal,0712

and then setting the session variable equal to the Cart session variable if it exists, and if not, creating a new Cart.0717

Well, in our new script, the session_start is replaced by instantiating this new SessionManager class.0724

It is going to implicitly call that session_start method.0730

And then, we load the class by making use of these methods that SessionManager provides.0733

For example, to test whether the Cart object exists, we call the inSession method on the SessionManager object.0738

If it exists, we return the value of that cart variable, using the getVar method that we defined in our SessionManager class.0746

And otherwise, it returns simply a new Cart object.0755

Similarly, in our last application, part of what we do when we view our cart is add and remove items from the cart.0759

So, we need to update that Cart object in the session.0765

Previously, we did that by directly accessing the _SESSION superglobal within our viewCart script,0768

so that now, that direct access...I'm not sure whether this is updated...this is incorrect...0775

it should be updated so that it calls the SessionManager setVar function...I don't know why that wasn't corrected.0785

So, in our new version, what should have been done was: now, when we save our session to the cart,0809

instead of directly saving it to the _SESSION superglobal, we call this setVar method0814

that we just talked about that is a part of the SessionManager class.0818

We provide the name of the session variable we want to set (which, for our particular application, is cart).0822

And then, we provide it the Cart object that we want to associate with that session variable name.0826

In checkout.php, we have replaced, at the beginning, the session_start method and the loading of the session cart0833

that uses direct access of the _SESSION superglobal, in the same way that we did in viewCart.php,0840

by creating a new instance of the SessionManager class, calling the inSession method to test if the cart session variable exists,0846

and then, if so, setting this cart variable equal to the session variable cartObject, using the getVar method of SessionManager.0854

Now, we don't save anything in this checkout form, so we don't call that setVar method.0866

But the thing that we do is: after an order is completed, the session functionality that we do is:0871

we destroy a session, or we try to end a session.0875

In our previous version, when we ended the session, if an order was successfully completed,0878

we simply just unset the cart variable by directly accessing the _SESSION superglobal.0887

What that effectively did was eliminated the cart, so that when we go back to viewCart, it no longer appears.0893

In our 12.0 example, if we were to add an item to a cart, and then we were to go to checkout,0899

two things to note are that...actually, let's refresh this page, so we can see our session ID;0931

if we look down here in Firebug, we can see that our session cookie is called jcp04.0938

So, if we look at our tmp directory, we can see that we have this session data file that starts with jcp04.0944

When we go ahead and submit this form, and click on Complete Order, we can see that that cookie still exists.0952

We haven't received a Set-Cookie response header from the server erasing that cookie.0976

So, as you can see, this was from the request going to this page;0986

but if we refresh this page, or even, for example, if we go back to viewCart,0991

we can see that we are still passing this session cookie, so our session cookie hasn't been deleted.1003

We can also see that our cart is empty, because we called that unset method on it.1008

But because we didn't also call session_destroy, if we go and look at our tmp directory,1013

we can see that that jcp session file is still there.1015

Well, in our new version, when we go to checkout.php and we successfully check out,1020

instead of just unsetting the session variable, we call the destroy method on SessionManager,1027

which is going to delete all the session variables, delete the session cookie, and then destroy the session data on the server.1034

So, in our new application (I'll delete any session cookies we have), if we add a winter jacket, for example, to our cart,1041

and go to check out, we can see that our new session is eg5dr.1053

So, if we look in our temporary directory, we see a data file for that eg5dr.1060

If we go ahead and check out again, now when we complete our order, we can see a couple things.1065

If we look at our Host headers, we can see that the cookie has been deleted.1084

We can see that there is a setCookie method that was called that deletes that session cookie.1088

If we look at our tmp directory, we can see that the data is no longer there.1094

It was called eg5dr; we can see that that data file is no longer there.1099

And in addition, if we try to view our cart again, we can see that the cart is going to show up as empty.1103

And that is because we have successfully deleted that session data.1109

And so, that is making use of that destroy function that we have created.1113

One thing to note is that, if we look at our destroy method, if any of these steps would have been eliminated--1119

for example, we commented out this destroySession here--that cookie would still remain.1132

If we commented out session_destroy, the data would still remain on the server.1136

We need all of these steps to properly destroy a session, and that is how we make use of this function on checkout.php.1141

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