Catálogo de publicaciones - libros

I can only hope Stephen Hawking doesn’t mind me paraphrasing his book title as the title of this chapter!1 Just as in his book A Brief History of Time , we are about to begin an exploration of a universe of sorts, from its humble beginnings to its current state of being.

I n this chapter, we’ll continue the discussion began in Chapter 1 and look in more detail at the art of making JavaScript a first-class language. We’ll look at object-oriented techniques, as well as some of the latest buzzwords such as unobtrusive JavaScript and graceful degradation . We’ll talk about how to make your web applications accessible, even with JavaScript involved (no easy task!). We’ll look at error-handling and debugging techniques, since things sometimes (OK, frequently !) don’t go right. We’ll also take a look at some of the tools available to you that will make working with JavaScript a much more pleasant experience. Lastly, we’ll do a quick survey of some of the most popular JavaScript libraries out there today, and discuss why you really, honestly, and truly want to be using them! That’s a lot to cover, so let’s get to it!

N o, we aren’t talking about the rabbit1 here. Programmers who have been coding for any length of time have invariably built up their own little private library of handy bits of code that they reuse from project to project. JavaScript is certainly no different in this regard. In this chapter, you’ll put together such a library for yourself—a library you’ll find numerous uses for in the projects to follow.

F rom Dustin Hoffman to Russell Crowe,^1 calculators have played an important role in the everyday lives of humans ever since the Babylonians first put stones on some lines in the sand (or was it the Chinese, as some pundits claim—I’m no historian, so I’ll leave that debate to more qualified folks). Why not bring the idea into the modern age and build one in JavaScript for ourselves?

A long time ago, some god-like developer came up with the concept of an Application Programming Interface (API). In short, an API is nothing but a known (to those that might use it) interface to a program or system. The developer came up with this idea, and everyone saw it, and saw that it was a Good Thing™. But, in the immortal words of Dr. Leonard H. McCoy, “. . . engineers, they love to change things.” We couldn’t just stick with the term API. No, we just had to come up with something new, and that something is the term mashup . Since it’s a term that is all the rage these days, and also something that often involves JavaScript to a large degree, it’s most definitely an appropriate topic for this book. So, in this chapter, I’ll introduce the concept of the mashup, and then we’ll put that concept to use in a handy little application.

F or applications, two types of data storage are available: persistent and nonpersistent , or transient. Persistent storage is any storage mechanism that provides a place for data to be saved between program executions, and often for an indefinite period of time (until explicitly removed from storage). Transient storage is any storage mechanism where the data lives only as long as the program is actually executing (or for some short time thereafter). A database is generally considered a persistent storage mechanism, whereas RAM clearly is not. Writing to a hard drive is usually persistent as well, while session memory generally is not. The term durable is also often used to describe persistent storage media.

I ’ll just come out and say it: parsing XML in a browser is not a particularly pleasant experience. Actually, if you think about it, parsing XML anywhere can be a bit of a hassle. However, one library that does make it a bearable experience is the Jakarta Commons Digester component (http://jakarta.apache.org/commons/digester). Digester allows you to specify a series of rules that will be triggered by various elements in an XML document. These rules may handle the parsing in a number of ways, including creating and populating objects from the XML. Wouldn’t it be great if we could do the same thing in JavaScript? Well, we’re going to make that dream a reality in this chapter, and in the process, make working with XML on the client a much less painful experience.

W hen you hear the word validation in the context of a web application, you generally think of validating user input on a form. This usually evokes thoughts of writing event-handler code to perform various checks on form input before submitting it. All of this can quickly become rather messy. No matter how well you externalize your scripts and set up basic event-handler code that just calls functions, the simple fact is that these validations are scattered throughout your code—it’s just a question of to what degree that’s true.

I n web development, widgets are all the rage these days. No longer are we content with regular form fields, buttons, drop-down lists, and such. Just plain-old tables aren’t sufficient for many developers! But this trend isn’t just due to a desire to create cooler interfaces. There are UI metaphors in a modern operating system that don’t have an analogy in the web world, at least not intrinsically.