tags on our page. Once all the content is loaded, we'll enable another element that is disabled by default. Here's the layout that we'll use: We're using CSS to style the divs and position them side-by-side. We're also using a radial gradient on each one just because. Notice the Proceed button is disabled. This page doesn't do anything yet. For now it's just showing the layout that we're going to use. Here's the HTML that produces this page: jQuery and a CSS file are referenced in the head section. We have a Load Button, three divs with unique IDs, a Proceed Button, and a div to hold any Messages we might use in debugging. And finally, there's an empty document ready function in the script block. Here's the CSS that is used for the page: It's pretty simple. Each section uses absolute positioning and has the same width and height. Since we're using Firefox, that's the only radial gradient that we have defined. If we wanted to have this work in multiple browsers, we'd need a different CSS gradient definition for each one, at least for now. The left position is the only style that is unique for each section. Since we want the divs to be side-by-side, we give each one a different left position. Notice the overflow-y style. Since we know we'll be loading content into a div after it has been rendered by the browser, we need to tell the browser how to handle content that won't fit within the div. If we don't have this style, the content will display beyond the borders of the div. With this style in place, a scroll bar will be added whenever the content exceeds the limits of the div. The Proceed button is also absolutely positioned, as is our Messages area. Now that we've looked at the head and body tags of the page, we can collapse them with Notepad++ so we can focus on the code that we need to use. If anything changes in the head or the body, we'll be sure to expand it and see what's new. Notice how our script tag starts on line 16. That shouldn't change unless we make some addition to the HTML. Our task is to load some dynamic content, so let's take a look at the first content page we want to load. Section 1 Content First, notice that this is a snippet of an HTML page. Most browsers will display the content even without a fully-formed web page. Firefox will display it just fine. It's not very exciting, but at least we know we should get some content when we load the page dynamically. Let's switch back to the main page and try loading the content in the first section. First of all, we only want to load the content when the Load button is clicked. Let's use jQuery to listen for the click on the Load button and run an anonymous function in response to the click. We've got an empty function just ready to do some work when the user clicks the Load button. There are many ways to accomplish what we want to do, even within the jQuery library. Probably the most common method in use is the Load method. Let's start with that. We'll put the Load command into the click function. It's pretty simple. We identify the element that we want to load the content into, Section1, and call the load method with the URL we want to load, Content1. Let's see what this gives us. As soon as we click the Load button, we get the new content right away. We see that everything is working for the load, but the Proceed button hasn't been enabled yet. As we ponder this, we recall that the load method in jQuery takes a callback function as a parameter. This function will be called when the load is completed. Let's give that a try and see if that works like we want. We'll add an anonymous function as a second parameter to the load method and just remove the disabled attribute from the Proceed button. Now that we have our callback function defined, let's give it a try. This is the pattern that is most commonly in use in websites. Everything seems to be working properly, but there are a couple of problems. The first one is the use of the callback function to enable the Proceed button. What happens when we need to load multiple content pages? Which ones should we put a callback function on? The other problem we'll encounter in just a moment, but for now we should know that we can't trust our eyes. Our first attempt looks good so far. We haven't introduced the second and third content pages. That's when we'll notice what's wrong with this example. We verified how processing works with the callback function, but we're still not using the deferred object. Loading All Content Let's load content in the other two sections. Content page 2 has a lot of text in it. We've placed a lot of text to simulate a page that will take a little longer to load. It just uses the lorem ipsum text that is standard in many demo pages. Content page 3 is a well-formed HTML page. Let's switch back to our main page and add the logic to load the contents. Here's what the code looked like when we left off. We'll add logic to add Content2 and Content3. Now when we run it we should see content in all three sections. Before we click the Load button, we need to pay close attention to the Proceed button. The content in the second section will take a little longer to load than the other two sections. In that delay, the Proceed button will actually be enabled. Watch closely. Here comes the click. As stated, the Proceed button was enabled prior to the content being loaded. In a case where it's not a button click but some page processing, we may need to make sure the page is fully loaded before we actually proceed with something that requires elements in the loaded content. This can be a really challenge to debug. Debugging timing problems can be very troublesome. Just the act of placing trace logic in the code can slow things down enough to make everything work as expected. When we remove the tracing logic, the strange behavior resumes. This is a very common problem. We've all heard more than one developer exclaim it works fine on my machine. We did put the callback on Section3. Section2 is the one that is taking a long time. Why not just move the callback to the longest section? First of all, that requires us to know which content will take the longest to load. Right now that's Section2, but in the future one of the other two sections may take longer. We can't base our logic on just what is happening right now. We have to expect the content will be different in the future. We really need to resist the urge to pick one specific load to attach a callback method to. What we really need is to be notified when each load is completed. Okay, what we really need is to know when all of the loads are complete. We'll get there, but let's investigate a little along the way. We're starting to expose some of the problems that are inherent to using the callback functions. Common Pattern We're going to take a look at a pattern that is in common use in many projects around the web. It's in use because the developer settled on it and never looked for another way. Here it is. Essentially, the code is the same as what we've seen so far. We're just nesting the calls to load content in a success callback of the previous load. So, once Content1 is loaded, we then start loading Content2. Once that's loaded, we start loading Content3. Finally, once that is loaded, we enable the Proceed button. This pattern works. That's why it's in use in so many projects. It's just that it has some issues. First of all, notice the multiple indents. This is called the Christmas tree effect. Each indent looks like a lower branch on a Christmas tree. The second problem is that it removes the asynchronous nature of the content loading. What's the point of using an asynchronous transport if we're just going to run it in a synchronous manner? Let's look at the results of this logic. Watch the content loading progression. Content1 loaded right away, and there was a perceptible pause for Content2. Content3 also appeared simultaneously with Content2 since it is so small. Let's think about this for a second. Just because we have to wait for all content to load before we can proceed with some logic doesn't mean the user should have to wait to see some data. Since our second content is the largest, that means the user didn't see the third content at all until the second was completed. What if the largest content was in the first section? The long delay would make most users think nothing was working. Few things are less interesting to web users than a blank screen. The final problem with this pattern is it can't be scaled. What if we wanted to load six content areas? What about 20? It won't take too many more indents before we can't even see our code on the screen. Sure there are other ways to format the code, but do we really want to change our coding style just to mask the problems of process logic? We really want to maintain asynchronous processes, be able to scale our solution, and also maintain it. Deferred Object Let's finally talk about the jQuery Deferred object. Even after reading the documentation about it, many people are left scratching their heads. First of all, consider the Load button that we've been clicking so far. Each time we clicked it we expected something to happen. We also expected nothing to happen until we clicked it. Simply put, our expectation could be stated as when the Load button is clicked, then perform this processing. Think about that for a second. The Load button click logic is actually an asynchronous process too. We have no idea the user will take to click the button or if they ever will click it. Only when the click occurs do we want to run the code in the click function. The same is true for our expectation of the Proceed button being enabled. Only when all content is loaded do we want to the Proceed button to become enabled. If the content is never loaded, we don't want the Proceed button to be enabled at all. We can put this simply by stating when all content is loaded then enable the Proceed button. Notice the way that's worded. When something happens, then do something else. That is the essence of the Deferred method in jQuery. Although it may seem to be the same as using a callback function, it is quite different. We'll explore those differences in a little bit. For now, let's see a Deferred in action. Notice the when and then methods. These are jQuery methods that we can use to organize our logic pattern. The when method returns a jQuery deferred object that we can make use of for later or deferred processing. The deferred object promises to notify our code upon completion of our process. We make use of that notification within the then method. This is the implementation of our expectation that was stated as when the content is loaded then enable the Proceed button. In this sample, we're using the get method within jQuery instead of load. Although both methods make use of the core AJAX functionality within jQuery, the Load method doesn't return a deferred object. The get method does. We want to make use of deferred's, so we're going to use the get method. Wait a minute. Earlier we talked about the when method returning a deferred object. That's right. The when method will group one or more deferred processes into a single code block and make a notification of completion when all code has finished. There is no need to place subsequent AJAX calls into a callback function of a previous AJAX call. Like the load method, the get method makes use of a callback when it succeeds. Using a callback in this case is no problem. In this case, the callback is appropriate because it returns data that is used to fill the contents of the div. The deferred object won't pass control to the then clause until that content is loaded. Unlike the load method, the get method doesn't place the contents in a div automatically. This makes sense because we called it directly from the jQuery reference dollar. The load method was called as part of a selected element. We'll use the callback function to load the contents, but not to determine if we should enable the Proceed button. The get method takes an additional parameter that specifies the type of content we want to load. Usually jQuery does a pretty good job of guessing the content type. We're going to remove the guess work and pass it a parameter that states we're dealing with HTML. We can wait for as many deferred's as we want. We just separate each one by commas. Once all deferred's have resolved, the function defined in the then method is executed. Let's see this in action. We'll have to watch carefully once we click the Load button. Contents 1 and 3 appeared immediately followed shortly by content 2. Then once all the content was loaded, the Proceed button was enabled. This is exactly what we wanted to accomplish. This pattern is extensible. We can add more content by simply adding more get methods within the when method. There's no Christmas tree indent issue either. Notice how the get methods all do pretty much the same thing but with different content and a different section. We could clean this code up quite a bit by using a single function to get the contents. Let's do that. Then we'll learn some more about the Deferred. We're really close with what we've got so far. If we want to make it really extensible, however, we need to move the repeated code in each of the callbacks to a single function. Imagine if we get requirements to do a few lines of code after each content is loaded. With what we've done so far, we'd have to duplicate those few lines of code in each success callback function. We're going to make sure we have a single function to allow for easy modifications and enhancements in the future. LoadSection Function We're writing our first new function since we talked about using object parameters earlier. We should use what we learned in the first module of this video and write a function that accepts a single object parameter. This will make sure we can modify it as much as we want in the future without fear of breaking a contract with existing code. We first start with our new loadSection function. It takes a single parameter called options. Even though we're just doing a demonstration, it's still prudent to follow some safety precautions. We verify that we have an object as our parameter. We then verify that the options object has selector and URL properties. We return the results of the get method, which is actually a deferred object. This makes the when block much more readable. It would be very easy to extend, and new sections could be easily loaded without breaking readability. Let's take a look at the result. It should perform exactly as the last example. It does in fact perform the same. That may bring up the question of why we changed the previous version then. If it was working, shouldn't we have left it alone? The answer to that depends on the definition of working. If we define working as just getting the desired output, then yes we could have left it alone. If we define working as getting the desired result in such a manner that is repeatable, extensible, and maintainable, then no it wasn't working and needed some adjustments. Before we leave this code, let's talk about a couple more points. Going back to the loadSection function, notice how I returned the result of the get method without actually doing any checks on the URL parameter. What happens if we pass in an invalid URL? What happens if we have a blank URL? We really need to plan for exceptions and make sure our code handles both positive and negative results. The function is working like we expect when called with a property-defined object parameter. Using the object parameter we're ready for future expansion. Having s single function reduces the code complexity for actually loading pages into sections and will make integrating changes to the logic much easier. Negative Testing We're going to do some negative testing now. This will also allow us to explore an alternate syntax available to use in the When/Then block. Here's the code as it stands right now. We recently asked what would happen if we used a bad URL. Let's change the first URL to something we know doesn't exist. In this case, we'll change it to Content11 instead of Content1. Now let's see what happens. Content 2 and 3 loaded as we expected. Content11 didn't load. Also, the Proceed button was not enabled. We didn't get an error message. Although the first load failed, the remaining two loaded just fine. One thing about JavaScript coding, once an error occurs, nothing works beyond that point. So, we obviously didn't get a JavaScript error while loading the first section; otherwise, the remaining two wouldn't have loaded. The When/Then block we're using says that when the three sections load then remove the disabled attribute from the Proceed button. There is nothing in that statement about what to do if we encounter a failure. That's a problem with our code, not a problem with the jQuery methods. There are actually a few ways we can address this. The first and simplest way is to attach an additional function to the then method. The first function that is passed to the then method is executed upon success. The second function, if present, is executed upon failure. Since we're not currently using a second function, we're not getting notified of the failure. Let's add a failure handler now. Here we've added an additional anonymous function that gets the result as a parameter. jQuery actually passes three parameters, but the first one is all we really care about. Interestingly enough, the parameter that is passed to us is an object. The result will contain a statusText property that describes the nature of the error. We retrieve that and add it to our Messages div that has been empty up to this point. Let's see it in action. Now we see that we did in fact get an error. Within the poorly worded error message we finally see that jQuery was unable to load the URI mostly because it's not defined. Why URI instead of URL? This message comes from the browser. jQuery was trying to load contents based on a URL. It passed the request to the browser Firefox, which can deal with much more than simple web pages. The acronym URI stands for Uniform Resource Identifier. This is used to reference web pages, images, videos, files, and pretty much any resource available to a computer, tablet, or smart phone. The browser processes in terms of URI, so that's why the error message uses that term instead of URL. Clear? Right. Back to our situation. We're getting our error message when something goes wrong, so our negative testing is doing what we expect. Let's put things back in order and see what happens with this new failure function when we don't expect an error. Here we've changed Content11 back to Content1. We'll run Firefox to see what we get not expecting an error. As expected, the page loaded properly, and we didn't see an error message. The second function was not executed because we had no failures. What happens if we get multiple failures? How many times will the error function be executed? Let's find out. Let's alter two of the URLs and see what we get. Here we've changed Content1 back to 11 and Content2 to 22. Let's see what this gives us. As we see, the error function is only executed one time regardless of how many errors are encountered. We'll look at a way to get around this in just a bit. Using two functions as parameters to the then method is a bit confusing to read, and it's not really clear what's going on, especially to the next developer that has to maintain this code. If they aren't familiar with the When/Then syntax, they're have little chance of understanding this code unless they do some research or we add some comments. There is another syntax that makes it much more readable. Instead of placing the failure function as a second parameter to the then method, we can promote it to be on the same level as then by using the fail method. Here's the new pattern. We're using the same anonymous function for failure as before. This time it's on the same level as the then method. We're using chaining to accomplish this. Chaining methods like this isn't unique to jQuery. It's actually just a core capability of JavaScript. The code reads like this: When the following functions are executed, return a deferred object that can be operated on. Upon success, then execute this function. Upon failure, execute this function. The result of the when method is a deferred object. That object gets passed to the then method, which sets up the handler for success. The then method also returns the same deferred object that gets passed to the fail method to set up the handler for failure. We need to be really clear about something. The when, then, and fail methods all execute almost immediately. There is very little delay between them. What they do is set up event handlers for deferred processing and specify what to do in case of success and failure. The then and fail functions get executed at some time in the future if ever at all. Let's dig deeper into this deferred object. Deferred Methods A deferred object is really just a wrapper that can be placed around asynchronous processing. Instead of trying to manage multiple success and failure callbacks for a series of asynchronous calls, the deferred object can wrap them all together into a single process that will work regardless of the sequence of completion. There are numerous methods associated with a deferred object. We'll talk about just a few. The jQuery documentation lists all of the methods currently available. Consider the When/Then block we've used so far. The when method returns a full deferred object to the code for subsequent operation. We could store this object in a variable and make use of it in various ways. So far, we've just changed some handler functions to the end of the when method and haven't done anything special with the deferred object. That's the most common pattern in use. The thing we need to be aware of is that jQuery is expecting to manage the state of that object for us. If we save the object as a variable, there is nothing to prevent us from altering the state of the deferred object possibly interfering with the process flow. The promise method returns just a subset of the deferred object that lets us attach handlers like we've been doing, but doesn't allow the state of the deferred object to be changed by us. We'll talk about this a little more in a moment. For now, realize that the promise method does return the deferred object. It's just not one that we can change the state of. Once we have a deferred object, even just the promise object, we can attach event handler functions to it. These functions will be called when the event associated with a name occurs for that object. We've seen the then method in action. It can take up to three handler functions as parameters. Those functions associate with success, fail, and progress. Instead of using three function parameters, we can use individual methods for each one also. The done method attaches a success handler function. The function will only execute when all processing completes successfully. The fail method attaches a failure handler function. It will execute if there is any error within the processing. This function is only called once regardless of the number of processing errors that are encountered. The progress method attaches a progress handler function. This is useful if a long-running process wants to report progress completion. This is most commonly used to update a progress bar to give the user a sense of how fast the process is working and how long before it completes. The always method attaches a function that will always execute after completion of the process whether it succeeded or failed. It's a good place to put any wrap up code that needs to execute no matter what the results of the processing were. There are two primary methods used to change the state of a deferred object, resolve and reject. As expected, the resolve method will change the state to indicate a successful completion, and the reject method will change the state to indicate failure. These methods can only be called upon a full deferred object. They are not available on a promise object. That's why returning a promise to client code is preferable to using a full deferred object. When we use a promise, we know that the client code can't change the state of our deferred object. Even when it's all internal code, it's best to expose only the promise instead of the deferred object just to be safe. With this latest information, let's go back to our code and make a few modifications. We've changed the then method to use the more accurately named done method. This makes sense because we're also making use of the fail method. In cases where we're only interested in the when and done, using the then method may make more grammatical sense. It's really a matter of preference. Basically it is better to use when and then in cases where we're only interested in success processing. It's better to use when, done, and fail in cases when we need to handle failure along with success. Notice that we're using the promise method after when. The when method returns a full deferred object that can have its state changed. Putting the promise method in the chain makes sure nothing we do accidentally changes the state. This code processes exactly like our previous code, so why should we take the extra step and use the promise method? The best answer is forming a habit of safety. By training ourselves to make use of the promise, we at least force ourselves to think about it if we decide to remove it. If we never use it, we'll have forgotten about what it does for us, and we may introduce some problems that become very difficult to debug. Remember how the proceed button doesn't get enabled when we have a failure when loading content? Let's imagine that our proceed logic just needs to make sure the loading process has completed, but doesn't necessarily need it to be successful or not. In that case, we can make use of yet another method, always. The always method will run as the last function call once all the success or failure functions are called. This would make a better choice for where to enable the Proceed button. Let's remove the code from the done method and add an always method. Let's check our results. It works fine when there's no error. Let's change a content URL to cause a failure. Here again we've changed Content1 to Content11. We see that even with an error the Proceed button is enabled. Everything is working just like we need. Okay. Before we leave this code segment, let's address the burning question on everybody's mind. What's the difference between using the done and fail methods instead of just using callback functions? Aren't they doing the exact same thing? Let's address what a callback function is. It's a piece of code that is passed as a parameter to a method. That code will be called upon completion of some processing accomplished by the method. That sounds exactly like what the done and fail methods are doing, right? Not exactly. The done and fail methods are registering a handler function with the deferred object. There is nothing to prevent registering multiple handlers for the done and fail methods. In fact, if we save the deferred object as a variable, we can attach a handler even after the object has been resolved or rejected. A callback method can only be called once from the original process that received it as a parameter. Assuming we're making a call to jQuery get, if we pass a callback to that method, it will only get executed once the get method completes. There is no way to expand the functionality of the callback after it has been executed because the get method has completed. If we use the deferred object that is returned from the get method instead, we can attach as many done or fail handlers as we wish in any order we wish and based on conditional processing. We can even add a handler based on the result of the get. The callback function falls very short of this capability. Let's take a look at some examples to really understand this. First of all, we'll return the page to a working state by referencing Content1 instead of Content11. Next, let's save the deferred object that's returned by the when method. We'll save it into a variable called myDefer. Now, just to prove the point, let's add an additional done method that puts a message in our message area. And now, after some unknown amount of code, we'll add another done handler. We're making use of the myDefer object we saved earlier. An unknown amount of processing happened between the when and then and making use of this object again. It is not part of the chain. It's a whole new set of functionality later in the code. Let's take a look at the results of having three distinct done handlers added to the deferred object. The three done handlers, one was still empty at this point, were processed in the order they were attached to the object. Once the deferred object was resolved, all three done handlers were executed. What would happen if we added another done handler even after the object had already been resolved? It would execute immediately. Let's take a look at that. Let's attach a done handler function from within a done handler function. This may seem to be a very unconventional approach, but it will prove the point of how versatile the handler functions are, especially in comparison to a simple callback function. We'll put it in the first empty done function. To be at this point in the code, the deferred object referenced by myDefer will be resolved. All done handlers will have processed already. The object may seem to have no further use, but we can still attach handler functions to it. Watch what happens when we run this code. Notice how the embedded done handler function was called after all other done handler functions. Since the deferred object was already in a resolved state when the handler was attached, it was executed immediately. This is a very powerful capability of deferred objects. You can conditionally add handler functions to them and have additional functionality occur. Using callback functions to accomplish the same thing would not be nearly as neat and maintainable. This code is easy to read, and each block of code can be omitted or included based on debug versus production states, local versus remote servers, or any number of other factors. Targeting embedded functionality within callback functions is not nearly as simple. We've made use of the deferred object that jQuery provides to us as part of the AJAX method get. There are other AJAX methods within jQuery that also return a deferred object. These methods can be used in the same way that we used get. There is one final scenario we need to discuss, and it breaks our code. Dynamic Pages So far, the content we've loaded dynamically has been static. Wait. Let's say that again. The dynamically loaded pages had static content. That means the content of each of the pages we load with the jQuery get method is the same each time. It's defined in the HTML and could easily be cached by our browser. What happens when content is loaded that is not static? Say there's some process on the server that needs to execute to provide different content. In that case, our logic could fail because we only monitor the successful loading of content and not whether any embedded scripts are executed. Let's take a look at a demonstration. The only difference in this code from our last version is that we're loading Content1a instead of Content1. Let's look at Content1a. This file still contains the static content defined in the HTML tag, but there's also a function that runs and loads some dynamic content. We're using a setTimeout function with a 2 second delay to simulate a long- running server process. At the end of 2 seconds, the function appends some text to the local div. Since it's also loaded in the main page, the dynamic content will show there as well. We'll switch back to our main page and see the result in Firefox. Let's watch the Proceed button to see when it gets enabled. Notice how the Proceed button was enabled prior to the dynamic content displaying. The deferred object used by jQuery was resolved as soon as the content was loaded. It had no way to know that a long-running process was executing in the background. We're going to fix this, but in small steps. First, we're going to rework our loadSection function so we can manage our own deferred object. Creating a Deferred Object The first change we're going to make is to use our own deferred object instead of making use of the one that jQuery provides with the get method. Since we're going to do that, we can go back to using the load method instead of the get. Remember, the load method doesn't return a deferred object, but the get method does. We switched to using the get method just so we could make use of the deferred object it returns. If we manage our own deferred object, there's no real reason to use the get method anymore. The loadSection function has really grown. Imagine for a moment that all this logic was still embedded in the when block. Remember when we moved the logic out so it wouldn't be duplicated over and over? Now we see another benefit to creating a function for that processing. Readability in the when block has improved, and we have a single point to make logic changes for all loading logic. Let's walk through the code piece by piece. First, we create our own deferred object using the jQuery Deferred method. We also define a variable that we'll use to reference the div that the content gets loaded into. Next, we check to make sure the options parameter is an object. This is our first opportunity to raise an error message. In our previous versions, we just fell through the function if something other than an object was passed. In this pattern, we make use of the reject method to report why the function failed. What, if anything, the calling code does with this information is not our concern. When writing functions that are part of an asynchronous process like this one, it is very important to think about how to handle failure as well as success. We don't know how this function will be used in the future or what project it may be copied to. By adding just a little thought up front, we can provide for a lot more possibilities down the road. Let's look more closely at how we're handling the error. Notice how we return the deferred object and reject it right away. This will trigger the fail method, which uses an object as the first parameter. We're creating a simple object that only contains the statusText property. This should be picked up by our fail function and reported to the message area on the page. After making sure the options parameter has selector and URL properties, we check to see if the URL property is an empty string. This is our second opportunity to report a meaningful failure result. Finally, we use jQuery to select the target div and check the length. If it's greater than 0 meaning we've found the selector element, we load the contents based on the URL. Within our success callback function, we manually resolve the deferred object. If the length is 0 meaning we didn't find the selector element, we return the deferred object with a rejected status and fill in the result text. Notice the last line of the function just returns the deferred object. Look through the code again. Up to this point, every place where you returned the deferred object was in response to an immediate error. For the first two errors, the deferred object we created wasn't even involved. We hadn't even attempted any asynchronous processing. Since the calling code expects to receive a deferred object as the result of this function, we needed to return one any place we encountered an error. To keep things tidy, we return a rejected deferred object to make sure the fail function was called. With the last block of code, we pass control off to jQuery to load the contents of the page. We have no idea how long that will take. We can immediately return the deferred object though. It will remain in a pending state until we either resolve it or reject it. This function does not actually wait on the load to complete. It just returns the deferred object, which will be resolved at some point in the future. As you can see, we resolve it in the success handler of the load method. What if the load method fails? As we know, a failure doesn't report any errors so we won't see any message, but will the defer get resolved? The answer is yes. jQuery calls a success callback upon completion of the load method regardless of whether it is truly successful or not. A better description of the success function would be to call it a completion callback function. The point is our deferred object will be resolved regardless of whether jQuery successfully loads the content or not. If we really needed to know about failures, we'd have to use the get method again instead of the load method. For now, we're sticking with the load method. Let's take a look at what our function does with our latest content. All the content loads properly, but the Proceed button gets enabled before the dynamic content in the first section appears. It seems we aren't any better off than we were previously. At least we're no worse off either. In just a moment we're going to make it all work and be far better than we were before. Right now though let's do some negative testing with our latest code. Let's call our loadSection function with no parameters. If you recall when we did that earlier, we got no indication of success or failure. It wasn't just that we didn't display an error. We weren't even notified that an error existed. What's going to happen now? Now we at least get an error message that is returned. For now we are choosing to display it, but we don't have to. The function notified the calling code of the existence of the error, but it didn't force any certain reaction to it. This is a step in the right direction. Perhaps we are slightly better off after all. Let's add a line with an empty object as the parameter. Wait a second! We're still getting the same error message. Are we sure the right code is running? Let's switch back and comment out the first error line just as a test. Here we've commented out the first loadSection that we expect an error from. Now we see the missing URL error message. Why didn't we see it before? Think about the deferred object we're using in the when block. The when method actually returns a deferred object, one that is different than what we create in our loadSection function. The deferred object used by when method is managed by jQuery. That makes sense because we call the when method directly on the jQuery library. As soon as any of the loadSection calls return a deferred that is rejected, the enclosing deferred object used by the when method is also rejected. Once a deferred is rejected or resolved, it cannot change state again. In short, the jQuery deferred object can only have one failure. As soon as that happened, all subsequent failures were ignored. What if we need to know more about each failure point? There's a way to manage that, but we have to do it on each deferred object we create, not within the enclosing object used by our when block. So, our dynamic content is still loading after the Proceed button is enabled, but we're getting notified of errors now, and not just generic errors, ones of our own design and text. Of course we're only seeing the first error we encounter. Using Deferred Objects We're going to bring everything together now. Get ready for this latest version. The code has really grown. Fortunately it's really just one main function that we're using. We have added a helper function that simply displays a message in our message area. As we provided for multiple error points, we noticed that we were duplicating the same code over and over. What does that mean? Time to move it to a function. Now if we ween to make changes to how we display an error message or maybe record them on a server somewhere, we only have to make changes in one place. We can also display non-error messages for debugging or informational purposes. We're following the rules and using a single object parameter for any options that this function takes or will take in the future. Notice what we do if we don't get an object parameter to this function. Since the purpose of this function is to display a message, we populate the object with an error message that indicates the function wasn't called properly. This may not be ideal for a production system. We're just using this as an example of an alternate way to set up a default parameter object. The loadSection has expanded a bit, but it's not really doing much more than it was before. It's just handling errors better. Notice how we're handling the lack of an object parameter now. Instead of only reporting an error to the calling code, we're also making an entry into the message area. We've made allowance for a third property on the parameter object. The dynamic property will default to false, so the calling code will have to set it to true when it's needed. What's it for? It's how the calling code indicates that the page that is being loaded also contains dynamic content. We add extra processing in that case, but there's no need to do it if the page to be loaded doesn't have dynamic content. Next we've expanded how we handle a missing URL error. Before, if we had two errors, we only saw the first one that was encountered. Now we're placing all error messages directly on the message div. We've gone back to using the get method instead of the load. Why? Because we want to be notified of any loading failures. The load method makes no distinction between completed with success or completed with a failure. It just reports when it finishes. We'll use the get method because it will return a deferred object to us. We pass an empty callback handler function to the get method. We're not really interested in a callback function. Now that we know how to use the done and fail methods, we would rather construct our code using those. The final parameter for the get method tells jQuery that we're loading HTML content. This is an obvious opportunity to extend our parameter object to let the calling code modify this if XML, JSON, or some other format needs to be loaded. We'll save that for another day. Notice how we resolve the deferred object in the done method for the get. If dynamic content is not expected, we can go ahead and resolve our object. That's because we don't have to worry about any long-running process that might be going on for the loaded page. If we encounter a failure with get, we'll report that and reject our deferred object and pass along the result from the get method. If dynamic content is expected, we first remove any event handlers for the complete and failure events. These are custom events that we're going to fire as needed. If this page gets reloaded over and over, it's possible to have multiple event handlers attached each time the page is refreshed. Using the off method removes any previous event handlers of the specified name. In this case, we're making sure that there are no event handlers for the complete event or the failure event. We'll look at how we trigger these events in just a moment. We follow up by adding event handlers to the div by using the on method. The on method is the opposite of off. It adds the specified function as an event handler for the named event or events. We were able to remove event handlers for complete and failure events with a single line. Since we want to do different things for each of these events, we specify different handlers for each one. First we handle the complete event. When we receive that event, we just resolve our deferred object. This event is fired when the dynamic content of our loaded page is completed. That means any content page will need to trigger this event when dynamic content is done loading. The failure event means something went wrong in the dynamic content, and we want to report it. Events can contain additional information, and we look for that in the result parameter. The event parameter contains the same kind of information available to any event used by the system such as click, blur, or mouseover. We're not really interested in that information. We really want to know what went wrong. That information is passed by the content page in the result parameter. After we report the error, we reject the deferred object with the result we received. Let's stop right here and look at how the content page can trigger these events. It's a very simple interface. We trigger the complete event on the Content1 div as soon we finish processing. Anything that's listening for that event will get notified. Notice that we're triggering the event on the locally defined Content1 div. Our loadSection code is listening for the event on the div with an ID of Section1. How can this work? The reason this works is because events bubble up the DOM. Since there's no event handler for Content1, the event rises up to the containing element. In this case, that's the div with an ID of Section1. That div does have a handler for this event, so it gets processed. Using this bubbling feature of JavaScript events, we can trigger the event on a local div that this code knows about. We can handle that event with an element higher up the DOM chain. This content page does not need to know anything about how it will be included in the main page. This lets the content page remain completely independent from the page that will make use of it. One more thing to notice before we leave this page. The timeout value has been increased to 5 seconds instead of the previous 2 seconds. That will make this the longest running process in our three samples. Let's look at how we can handle a failure event. The failure event is triggered just like we did for the complete event. In this case, however, we pass an object parameter, which contains our statusText message. As before, the event is triggered on a local div, and we're counting on event bubbling to pass the event up to the containing div on our main page. Back to our loadSection function, there's just one more condition we have to handle. We've expanded the error handling used in case the selector can't be found. Now we're displaying an error message, as well as rejecting the deferred object. Finally, we change the return value to be a promise and not the whole deferred object. This means we can be certain that the calling code will not interfere with how the deferred object gets resolved. Let's look at how we can use this new logic. First of all, notice that we've included calls to the showMessage function. How can that work? It doesn't return any results much less a deferred object. This is yet another powerful feature of the jQuery deferred object. Remember, the when method creates a deferred object that processes a group of other deferreds. If any of the processes don't return a deferred object as our showMessage function doesn't, it will treat that function as being a resolved deferred object by default. That means we can intermingle synchronous processes with asynchronous processes. Any synchronous processes will be resolved immediately, and processing will continue when the asynchronous process is complete. Think of how we would have to structure our code to accomplish the same thing without using derferreds. It would be very messy and certainly difficult to maintain. Notice how the loadSection function calls for Content1b and Content3a at the additional dynamic property. What would happen if we forgot to include this? If we omit the dynamic property when loading a page that has dynamic content, the deferred object would be resolved before the dynamic content finishes loading. That's the behavior we've seen so far. By including this property, we inform the loadSection function to wait for the complete or failure events before resolving or rejecting the deferred object. What would happen if we include the dynamic property for a page that doesn't trigger the complete or fail event? The deferred object used by the when method would never resolve. We'd have to have some sort of master monitoring process that looked for that contingency. Let's take a look at this latest version. Finally. The Proceed button didn't get enabled until all the dynamic content was loaded. Our page is working just as we want. Many developers would stop right here. We know better, however. We know that we should do some negative testing. Let's start breaking things to see what happens. Let's see what happens when we give it a bad URL. Remember, before we got a cryptic URI message. Here I changed Content1b to Content1bb. We get two error messages. The first one is generated by the loadSection function. Notice how it is more useful because it gives the URL that can't be located. Why did we get two messages? We got two because the second message is in response to our fail method that's part of the when block. Since our eyes were immediately drawn to the error message, we may have missed a very important point. Let's watch the load process again. This time pay attention to section 3 and the Proceed button. Ha, ha. The Proceed button is enabled right away. Earlier it waited until the dynamic content was loaded before being enabled. Here's some information that will make this entire video worthwhile. We're about to shorten hours of debugging into a simple little-known fact. When we reject our deferred object, that immediately rejects the deferred object used by the when block. That causes the failed process and also causes the always method to immediately process. See, once the state of a deferred object is established, it can't be changed. Let's take a look at what our logic flow is. The way we've written our code, the logic flow could easily be stated as when processing these embedded functions, run the done function immediately upon success or run the fail function immediately upon failure. Then run the always function right away too. That's exactly what is happening in this case. Since we've purposely introduced negative test into this process, we're encountering something that may not become apparent for a very long time. Under normal circumstances, this situation may not present itself for months. When it finally comes up, we will be working on some other project and will have to relearn what we've done on this project. Let's take care of this right now. Now that we know what's going on, how do we approach it differently? What we really want our logic to be is when processing the embedded functions, report errors to the message area and keep processing. When everything is processed, enable the Proceed button. The key point of that logic is that we're handling the errors directly in the loadSection function. There is really no need to ever reject the deferred object that we're using. Once we report the error message, we can really resolve the deferred. Keep in mind the only thing we're doing in the fail logic is duplicating the error message. Let's change all our reject methods to resolve methods and see if that gives us what we want. We've changed all the reject methods to resolve. In those cases where we called reject with a result, we can still pass the result with resolve. We just won't be using it. Let's run Firefox again and see how things work now. Remember, the Proceed button was enabled before the dynamic content in section 3 was loaded. Now, that's more like it. The Proceed button doesn't enable until after the dynamic content is loaded even when an error is present. This is a very important point to take away from this video. When we write our logic, we must consider what will happen when, not if we get an error. We must ensure that our logic doesn't fall apart just because of an unexpected circumstance. Let's throw some more error situations at our loadSection function. Remember how we tested with no parameter? We'll put that test back in. Let's also add an empty parameter object. Let's check what happens with these two new errors. We get all our error messages, and the Proceed button still waits for the dynamic content. Our failure processing is working well. Speaking of failures, we looked at Content3b. It's the one that raises our custom failure event. Let's load that instead of loading Content3a. Let's also test the error we get when we pass in an invalid selector. Finally, we'll change Content1bb back to Content1b and change the dynamic property to false. This should test what happens when we don't look for our custom events. Keep in mind Content1b has the extended timeout of 5 seconds. If we don't set the dynamic property to true, the loadSection function won't know to wait on the dynamic content. Here we go. A lot just happened. Content 1 loaded, and there was no problem with the dynamic property set to false. The dynamic content still loaded. We just didn't get a proper notification of when it completed. The proceed button still enabled as soon as the content in section 3 was loaded. In this case, the error lies with the programmer, not the function. All we have to do is change the dynamic property back to true, and the process will behave as we expect. Let's run this one last time. Fixing that problem was easy. If we could fix all programmer problems so easily, we wouldn't ever have to worry about sitting in a cubicle again. We've come a long way with our deferred processing. If we take anything away from this segment, it should be how important negative testing is when dealing with asynchronous processes. Summary Deferred objects are difficult to explain unless they can be viewed in action. Hopefully this video provided some insight into how they can be used. When asynchronous processes are involved, a deferred object is a very good candidate for use, even if there is only process in place. We can benefit by using deferred objects in our own functions as well. We should remember to return the promise instead of the full deferred object. This makes sure that the object only gets resolved or rejected by code we control. There are some other used for deferred objects: Animation, user inputs, background processing, basically anything that needs to process and return a result at some point in the future. The deferred object can be saved in a variable, and additional event handlers can be attached to it in the future even if it's already been resolved or rejected. Any attached handler functions will be processed immediately if the object has already been resolved or rejected. That's something that can't be done with a callback function. The code samples in this video are a good starting template for making use of deferred objects in your own projects. Feel free to use them. Thank you for taking the time to watch this video. I hope you found it beneficial. As always, happy coding. Course author Kevin Murray Kevin is a lifelong learner with over 30 years in the IT industry. He works on web and mobile applications as well as the databases and web services to support them. With a gift for learning new... Course info LevelIntermediate Rating (565) My rating Duration3h 16m Released14 Nov 2013 Share course