474 Part II: Developing an Ajax Library^
Features like send it to a friend or bookmark it for later use would suffer from the same
problem as the Ajax application because in some situations it may lack the necessary data
(cookie) or browser-cached data to put it back to the desired state. We can engineer around
all this, but it means you need to make sure your history states contain unique enough
information for the global history callback function to look at it and set things right without
having necessarily to go to the local persistence. That is going to be some work, and there
simply is no automatic solution here that will be clean. Either some special URLs must be
generated that people should send to friends, as we saw Google do, or the hash states must
save the similar amount of data in them directly and then handle all of that data in the
callback function.A Full Example: To-Do List
In the previous chapter, we presented the user interface concerns surrounding an online to-
do list. Here we go ahead and fully implement the list using a number of the concepts from
this chapter. Given that the code is a bit involved, we are only going to highlight some
interesting aspects of the design and present a discussion of how the application was put
together. For fine details, you should download the entire code yourself from http://ajaxref
.com/ch9/todolist.html.
Upon login, we profile the user to see if they are running JavaScript with Ajax or not. The
login form will utilize JavaScript to use an XHR to log the user in if it can. If the script is off, it
does a normal form post. The receiving server-side application looks at this and redirects the
user to one of two pages, listajax.php or list.php. We could combine the two if we wanted, but
it is a bit easier to keep them separate. In the course of using the application, if JavaScript is
started enabled and then is disabled, a <noscript> in the Ajax version will redirect to the
main list page for the traditional version. In the traditional, if the script becomes enabled, a
simple window.location script sends the user back the Ajax version. The general interaction
between the two styles is shown in Figure 9-15.
There were some interesting design decisions to be made as well during the implementation
of the example. For instance, when adding an item to the list in an Ajax style, there are a few
approaches to choose from. The first choice is after adding an item, we could return the
whole list and repopulate. With templates, that won’t be difficult, but it seems inappropriate
to do as needless data would be transmitted at each request. The second choice might be to
simply send back a status code that indicates the item was added successfully. Generally, this
would be the DOM id value of the item for later use. The third choice would be to send back
an echo of what was added as confirmation including any new generated data, such as the
DOM id value or date of submission and so on. The second and third choices are better from
a network usage point of view, but they add some script complexity since now you have to
figure out how to add in the newly inserted item properly. We use a single row template to
do this that is quite clean, but you could certainly use the DOM as well.
Another concern for the Ajax application is the question of whether to wait for a
response from the server to update the page or to do the work and then verify that the
update was successful. Clearly, the latter is better because there are no delays waiting for
confirmation, but again that adds more work if there is a failure. For example, in a delete,
the record would be automatically deleted, but if the confirmation code comes back bad the
record must be put back in. Similarly, on the add, the new row could be put in right away,