348 Part II: Developing an Ajax Library^
NNOT EOTE Depending on your application, if you can get access to content as it comes in, you may wish
to provide it for use immediately rather than just discussing the progress unless there is some
need to wait until completion.If some long process is running, you may also want to inform the user of the status of
the effort. For example, when fetching data from many Web Services to combine in a mash-
up or running large queries, you might decide to show status as you go along. The
approach is similar to the file upload in that one request will be running the actual data
retrieval and another will be monitoring progress. A faked example of such an application is
shown in Figure 8-6 and can be found at http://ajaxref.com/ch8/queryprogress.html.Communicating Problems and Errors
In the last section, we discussed the various techniques required to let users know that some
form of network activity is happening. Accepted practice or not, the harsh reality is that
spinning image is not terribly informative. If a network connection gets hung up, a user
may be watching a spinning icon with no idea what is going on. Ajax developers must
practice contingency-based design and if possible, gracefully recover from errors and, if not,
alert users to the situation. The standard JavaScript alert dialog is not visually pleasing and
this example message is uninformative.Yet this example is far superior to showing no indication at all that an error has occurred
as in most situations. In slightly better cases, a very subtle indication will display, like a
brief icon change in the corner of the window due to an inherent JavaScript error thrown by
the unexpected network circumstance. This may be the only clue the user has that
something has gone awry other than the application simply not working properly or, even
worse, appearing to work properly even though it is not saving any data to the server or is
providing stale data.Ajax developers must handle their JavaScript and network errors properly. As discussed
in Chapters 2 and 3, techniques like the <noscript> tag, try-catch blocks and the
window.onerror handler can be used to address various JavaScript related contingency
cases. Chapter 6 discussed numerous types of network concerns and offered potential
methods to handle such situations. In either case, if at all possible, client-side errors should
be communicated back to the server using either a standard XHR or maybe a lightweight
technique such as the Image object request method as discussed in the section “A Client-Side
JS Error Reporter” in Chapter 2.