Head First Ajax

Table of contents

1. Head First Ajax
2. A Note Regarding Supplemental Files
3. Advance Praise for Head First Ajax
4. Author of Head First Ajax
5. How to Use this Book: Intro
   1. Who is this book for?
      1. Who should probably back away from this book?
   2. We know what you’re thinking
   3. We know what your brain is thinking
   4. Metacognition: thinking about thinking
   5. Here’s what WE did
   6. Here’s what YOU can do to bend your brain into submission
   7. Read Me
   8. The technical review team
   9. Acknowledgments
   10. Safari® Books Online
6. 1. Using Ajax: Web Apps for a New Generation
   1. Web pages: the old-fashioned approach
   2. Web pages reinvented
   3. So what makes a page “Ajax”?
   4. Rob’s Rock ‘n’ Roll Memorabilia
   5. Ajax and rock ‘n’ roll in 5 steps
   6. Step 1: Modify the XHTML
   7. Step 2: Initialize the JavaScript
      1. To set up the onclick behavior for the thumbnails, the initPage() function has to do two things
   8. Step 3: Create a request object
   9. Step 4: Get the item’s details
   10. Let’s write the code for requesting an item’s details
   11. Always make sure you have a request object before working with it
       1. And here’s how that looks in our code...
   12. The request object is just an object
       1. Let’s break open() down a bit...
   13. Hey, server... will you call me back at displayDetails(), please?
   14. Use send() to send your request
   15. The server usually returns data to Ajax requests
       1. Traditional server-side interactions
       2. Ajax server-side interactions
   16. Ajax is server-agnostic
   17. Use a callback function to work with data the server returns
   18. Get the server’s response from the request object’s responseText property
   19. Goodbye traditional web apps...
7. 2. Designing Ajax Applications: Thinking Ajaxian
   1. Mike’s traditional web site
   2. Let’s use Ajax to send registration requests ASYNCHRONOUSLY
   3. Update the registration page
   4. Set the window.onload event handler... PROGRAMMATICALLY
   5. Code in your JavaScript outside of functions runs when the script is read
   6. What happens when...
   7. And on the server...
   8. Some parts of your Ajax designs will be the same... every time
   9. createRequest() is always the same
   10. Create a request object... on multiple browsers
   11. Ajax app design involves both the web page AND the server-side program
   12. What we’ve done so far...
   13. What we still need to do...
   14. The request object connects your code to the web browser
   15. You talk to the browser, not the server
   16. The browser calls back your function with the server’s response
   17. Show the Ajax registration page to Mike...
   18. The web form has TWO ways to send requests to the server now
   19. Let’s create CSS classes for each state of the processing...
   20. ... and change the CSS class with our JavaScript
   21. Changes? We don’t need no stinkin’ changes!
   22. Only allow registration when it’s appropriate
8. 3. Javascript Events: Reacting to your users
   1. It all started with a downward-facing dog...
   2. Ajax apps are more than the sum of their parts
   3. Here’s Marcy’s XHTML...
   4. Events are the key to interactivity
   5. Connect events on your web page to event handlers in your JavaScript
   6. Use the window.onload event to initialize the rest of the interactivity on a web page
   7. Change those left-side images to be clickable
   8. Use your XHTML’s content and structure
      1. Every XHTML element is accessible in your JavaScript code as an object
   9. Add the code for hideHint(), too
   10. Tabs: an optical (and graphical) illusion
       1. To make a tab active, we need to change the tab’s background to the “active” color
   11. Use a for... loop to cycle through the images
   12. CSS classes are the key (again)
   13. Ummm... but the tabs aren’t < a >’s !
   14. This broke our JavaScript, too, didn’t it?
   15. Use a request object to fetch the class details from the server
   16. Be careful when you have two functions changing the same part of a web page
       1. Marcy wants the images on the left to change when users roll their mouse over the image
   17. When you need to change images in your script, think “change CSS classes” instead
   18. Links in XHTML are represented by <a> elements
   19. We need a function to show an active button and hide a button, too
       1. When you initialize the page, you need to assign the new event handlers
9. 4. Multiple Event Handlers: Two’s company
   1. An event can have only one event handler attached to it (or so it seems)
      1. Only the LAST event handler assigned gets run
   2. Event handlers are just properties
   3. A property can have only ONE value
   4. Assign multiple event handlers with addEventListener()
   5. Your objects can have multiple event handlers assigned to a single event in DOM Level 2
      1. The browser runs every handler for an event when that event is triggered
   6. What’s going on with Internet Explorer?
   7. Internet Explorer uses a totally different event model
   8. attachEvent() and addEventListener() are functionally equivalent
   9. addEventHandler() works for ALL apps, not just Marcy’s yoga page
   10. Let’s update initPage() to use our new utility function
   11. Use an alert() to troubleshoot
   12. So what else could be going wrong?
   13. Event handlers in IE are owned by IE’s event framework, NOT the active page object
   14. attachEvent() and addEventListener() supply another argument to our handlers
       1. Your event handlers get an Event object from attachEvent() and addEventListener()
   15. We need to name the Event argument, so our handlers can work with it
   16. You say target tomato, I say srcElement tomato...
   17. So how do we actually GET the object that triggered the event?
10. 5. Asynchronous Applications: It’s like renewing your driver’s license
    1. What does asynchronous really mean?
       1. A synchronous request for cola
       2. An asynchronous request for cola
    2. You’ve been building asynchronous apps all along
    3. But sometimes you barely even notice...
    4. Speaking of more server-side processing...
       1. Oh, and password verification...
       2. And... how about some eye candy, too?
    5. (More) Asynchrony in 3 easy steps
    6. We need two password fields and a <div> for the cover images
    7. If you need new behavior, you probably need a new event handler function
    8. With ONE request object, you can safely send and receive ONE asynchronous request
    9. Asynchronous requests don’t wait on anything... including themselves!
    10. If you’re making TWO separate requests, use TWO separate request objects
        1. Right now, we disable the Register button in initPage()...
        2. ... and enable the button in the callback functions
    11. Asynchrony means you can’t count on the ORDERING of your requests and responses
    12. A monitor function MONITORS your application... from OUTSIDE the action
    13. You call a monitor function when action MIGHT need to be taken
        1. Right now, the username and password callbacks directly update the Register button’s status
        2. Let’s have the callbacks run the monitor function...
        3. ... and let the monitor function update the Register button
    14. Status variables let monitors know what’s going on
    15. And now for our last trick...
    16. Synchronous requests block ALL YOUR CODE from doing anything
        1. First, we no longer need a “submit” button
        2. Second, we need to register a new event handler for the button’s onclick event
        3. Third, we need to send an ASYNCHRONOUS request to the server
    17. Use setInterval() to let JavaScript run your process, instead of your own code
11. 6. The Document Object Model: Web Page Forestry
    1. You can change the CONTENT of a page...
    2. ... or you can change the STRUCTURE of a page
    3. Browsers use the Document Object Model to represent your page
       1. The document object is just an OBJECT
    4. Here’s the XHTML that you write...
    5. ... and here’s what your browser sees
    6. Your page is a set of related objects
    7. Let’s use the DOM to build a dynamic app
       1. We’re not replacing content, we’re moving it
    8. You start with XHTML...
    9. appendChild() adds a new child to a node
       1. A new child gets a new parent... automatically
    10. You can locate elements by name or by id
    11. Can I move the clicked tile?
    12. You can move around a DOM tree using FAMILY relationships
    13. A DOM tree has nodes for EVERYTHING in your web page
        1. Those spaces are nodes, too
    14. The nodeName of a text node is “#text”
        1. swapTiles() and cellIsEmpty() don’t take whitespace nodes into account
    15. Did I win? Did I win?
    16. But seriously... did I win?
12. 7. Manipulating the DOM: My wish is your command
    1. Webville Puzzles... the franchise
    2. Woggle doesn’t use table cells for the tiles
    3. The tiles in the XHTML are CSS-positioned
    4. “We don’t want TOTALLY random letters...”
    5. Our presentation is ALL in our CSS
       1. Now the designers have options
    6. We need a new event handler for handling tile clicks
    7. Start building the event handler for each tile click
    8. We can assign an event handler in our randomizeTiles() function
    9. Property values are just strings in JavaScript
    10. We need to add content AND structure to the “currentWord” <div>
    11. Use the DOM to change a page’s structure
    12. Use createElement() to create a DOM element
    13. You have to TELL the browser where to put any new DOM nodes you create
        1. The nodeName and nodeValue properties tell you about nodes
    14. We need to disable each tile. That means changing the tile’s CSS class...
    15. ... AND turning OFF the addLetter() event handler
    16. Submitting a word is just (another) request
    17. Our JavaScript doesn’t care how the server figures out its response to our request
    18. Usability check: WHEN can submitWord() get called?
        1. You can’t submit a word if there’s no word to submit
13. 8. Frameworks and Toolkits: Trust No One
    1. So what frameworks ARE there?
    2. Every framework uses a different syntax to do things
    3. The syntax may change... but the JavaScript is still the same
    4. To framework or not to framework?
    5. The choice is up to you...
14. 9. XML Requests and Responses: More Than Words Can Say
    1. Classic rock gets a 21st century makeover
    2. How should a server send a MULTI-valued response?
    3. InnerHTML is only simple for the CLIENT side of a web app
    4. You use the DOM to work with XML, just like you did with XHTML
    5. XML is self-describing
15. 10. JSON: SON of JavaScript
    1. JSON can be text AND an object
    2. JSON data can be treated as a JavaScript object
    3. So how do we get JSON data from the server’s response?
    4. JavaScript can evaluate textual data
    5. Use eval() to manually evaluate text
    6. Evaluating JSON data returns an object representation of that data
       1. But there’s one catch...
    7. JavaScript objects are ALREADY dynamic... because they’re not COMPILED objects
    8. You can access an object’s members... and then get an object’s values with those members
    9. You need to PARSE the server’s response, not just EVALUATE it
    10. So which is the better data format?
16. 11. Forms and Validation: Say what you meant to say
    1. Marcy’s Yoga for Programmers... a booming new enterprise
    2. Validation should work from the web page BACK to the server
    3. You can validate the FORMAT of data, and you can validate the CONTENT of data
    4. We need to validate the FORMAT of the data from Marcy’s enrollment page
    5. Don’t Repeat Yourself: DRY
    6. Let’s build some more event handlers
    7. RETURN of SON of JavaScript
    8. The value of a property can be another JavaScript object
    9. Let’s warn Marcy’s customers when there’s a problem with their entry
    10. If you don’t warn(), you have to unwarn()
    11. IF there’s a warning, get rid of it
    12. Duplicate data is a SERVER problem
        1. You could do this with an asynchronous request...
        2. ... but what’s the benefit?
    13. So we’re done now, right?
17. 12. Post Requests: Paranoia: It’s your friend
    1. There’s a villain in the movies
    2. GET requests send request parameters across the network as clear text
       1. Clear text is text... in the clear!
    3. POST requests DON’T send clear text
       1. GET requests send data in the request URL
       2. POST requests send data separate from the request URL
    4. The data in a POST request is ENCODED until it reaches the server
    5. send() your request data in a POST request
    6. Always check to make sure your request data was RECEIVED.
    7. Why didn’t the POST request work?
    8. The server unencodes POST data
    9. We need to TELL the server what we’re sending
       1. Servers get information from the browser via REQUEST HEADERS.
       2. Servers send information to the browser using RESPONSE HEADERS.
    10. Set a request header using setRequestHeader() on your request object
18. A. Leftovers: The Top Five Topics (we didn’t cover)
    1. #1 Inspecting the DOM
    2. Inspecting the DOM in Internet Explorer
    3. Inspecting the DOM in Safari
    4. #2 Graceful degradation
    5. #3 script.aculo.us and the Yahoo UI libraries
       1. script.aculo.us
       2. Yahoo UI (YUI)
    6. #4 Using JSON libraries in your PHP code
    7. Using JSON in PHP 5.1 and earlier
    8. #5 Ajax and ASP.NET
    9. You don’t NEED ASP.NET Ajax to build Internet Explorer-compatible web apps
19. B. Utility Functions: Just Gimme the Code
    1. utils.js: a work in progress
20. Index
21. About the Author
22. Copyright