AJAX In Action [83]
Looking at the View subsystem, we demonstrated how to effectively separate presentation from logic, with the very practical benefit of allowing designer and programmer roles to be kept separate. Maintaining clear lines of responsibilities in the codebase that reflect your team’s organizational structure and skill sets can be a great productivity booster.
In the Controller code, we looked at the different event models available to Ajax and erred on the side of caution toward the older event model. Although it is limited to a single callback function for each event type, we saw how to implement the Observer pattern to develop a flexible, reconfigurable event-handler layer on top of the standard JavaScript event model.
Regarding the Model, we began to address the larger issues of distributed multiuser applications, which we will explore further in chapter 5. Looking after a Model, a View, and a Controller can seem like a lot of work. In our discussion of the ObjectViewer example, we looked at ways of simplifying the interactions between these using automation, and we created a simple system capable of presenting an object model to the user and allowing interaction with it. We’ll continue to draw upon design patterns as we move on to explore client/
server interactions in the next chapter.
Licensed to jonathan zheng 158 CHAPTER 4 The page as an application 4.7 Resources The Behaviours library used in this chapter can be found at http://ripcord.co.nz/ behaviour/. Mike Foster’s x library can be found at www.cross-browser.com. Autogeneration of the View from the Model is a technique inspired by the Naked Objects project (http://www.nakedobjects.org/). The book Naked Objects (John Wiley & Sons, 2002), by Richard Pawson and Robert Matthews, is somewhat out of date as far as the code goes, but provides an incisive critique of hand-coded MVC in the opening sections. The images of the planets used in the ObjectViewer are provided by Jim’s Cool Icons (http://snaught.com/JimsCoolIcons/), and are modeled using the POVRay modeler and textured with real images from NASA (according to the website)! Licensed to jonathan zheng The role of the server This chapter covers ■ Using current web framework types with Ajax ■ Exchanging data with the server as content, script, or data ■ Communicating updates to the server ■ Bundling multiple requests and replies into a single HTTP call 159 Licensed to jonathan zheng 160 CHAPTER 5 The role of the server This chapter concludes the work that we started in chapter 4: making our applications robust and scalable. We’ve moved from the proof-of-concept stage to something that you can use in the real world. Chapter 4 examined ways of structuring the client code to achieve our goal; in this chapter, we look at the server and, more specifically, at the communication between the client and the server. We’ll begin by looking at the big picture and discuss what functions the server performs. We’ll then move on to describe the types of architectures commonly employed in server-side frameworks. Many, many web frameworks are in use today, particularly in the Java world, and we won’t try to cover them all, but rather we’ll identify common approaches and ways of addressing web application development. Most frameworks were designed to generate classic web applications, so we’re particularly interested to see how they adapt to Ajax and where the challenges lie. Having considered the large-scale patterns, we’ll look at the finer details of communicating between client and server. In chapter 2 we covered the basics of the XMLHttpRequest object and hidden IFrames. We’ll return to these basics here as we examine the various patterns for updating the client from the server and discuss the alternatives to parsing XML documents using DOM methods. In the final section, we’ll present a system for managing client/server traffic over the lifetime of the application, by providing a client-side queue