Test Driven JavaScript Development- P17

Test Driven JavaScript Development- P17:This book is about programming JavaScript for the real world, using the techniquesand workflow suggested by Test-Driven Development. It is about gaining confidencein your code through test coverage, and gaining the ability to fearlessly refactor andorganically evolve your code base. It is about writing modular and testable code. Itis about writing JavaScript that works in a wide variety of environments and thatdoesn’t get in your user’s way.
Nội dung trích xuất từ tài liệu:
Test Driven JavaScript Development- P17 13.1 Polling for Data 313 Next up, Listing 13.32 makes sure the url property is set on the poller. In order to make this assertion we need a reference to the poller object, so the method will need to return it. Listing 13.32 Expecting the url property to be set test should set url property on poller object: function () { var poller = ajax.poll(/url); assertSame(/url, poller.url); } Implementing this test requires two additional lines, as in Listing 13.33. Listing 13.33 Setting the URL function poll(url, options) { var poller = Object.create(ajax.poller); poller.url = url; poller.start(); return poller; } The remaining tests will simply check that the headers, callbacks, and interval are set properly on the poller. Doing so closely resembles what we just did with the underlying poller interface, so I’ll leave writing the tests as an exercise. Listing 13.34 shows the final version of ajax.poll. Listing 13.34 Final version of ajax.poll function poll(url, options) { var poller = Object.create(ajax.poller); poller.url = url; options = options || {}; poller.headers = options.headers; poller.success = options.success; poller.failure = options.failure; poller.complete = options.complete; poller.interval = options.interval; poller.start(); return poller; } ajax.poll = poll;Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 314 Streaming Data with Ajax and Comet 13.2 Comet Polling will definitely help move an application in the general direction of “live” by making a more continuous data stream from the server to the client possible. However, this simple model has two major drawbacks: • Polling too infrequently yields high latency. • Polling too frequently yields too much server load, which may be unnecessary if few requests actually bring back data. In systems requiring very low latency, such as instant messaging, polling to keep a constant data flow could easily mean hammering servers frequently enough to make the constant requests a scalability issue. When the traditional polling strategy becomes a problem, we need to consider alternative options. Comet, Ajax Push, and Reverse Ajax are all umbrella terms for various ways to implement web applications such that the server is effectively able to push data to the client at any given time. The straightforward polling mechanism we just built is possi- bly the simplest way to do this—if it can be defined as a Comet implementation—but as we have just seen, it yields high latency or poor scalability. There are a multitude of ways to implement live data streams, and shortly we will take a shot at one of them. Before we dive back into code, I want to quickly discuss a few of the options. 13.2.1 Forever Frames One technique that works without even requiring the XMLHttpRequest object is so-called “forever frames.” A hidden iframe is used to request a resource from the server. This request never finishes, and the server uses it to push script tags to the page whenever new events occur. Because HTML documents are loaded and parsed incrementally, new script blocks will be executed when the browser receives them, even if the whole page hasn’t loaded yet. Usually the script tag ends with a call to a globally defined function that will receive data, possibly implemented as JSON-P (“JSON with padding”). The iframe solution has a few problems. The biggest one is lack of error hand- ling. Because the connection is not controlled by code, there is little we can do if something goes wrong. Another issue that can be worked around is browser loading indicators. Because the frame never finishes loading, some browsers will (rightfully so) indicate to the user that the page is still loading. This is usually not a desirablePlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 13.3 Long Polling XMLHttpRequest 315 feature, seeing as the data stream should be a background progress the user doesn’t need to consider. The forever frame approach effectively allows for true streaming of data and only uses a single connection. 13.2.2 Streaming XMLHttpRequest Similar streaming to that of the forever frames is possible using the XMLHttp- Request object. By keeping the connection open and flushing whenever new data is available, the server can push a multipart response to the client, which enables it to receive chunks of data several times over the same connection. Not all browsers support the required multipart responses, meaning that this approach cannot be ...