AJAX In Action [67]
Licensed to jonathan zheng A different kind of MVC 123 Figure 4.3 Nested MVC architecture, in which the pattern repeats itself at different scales. At the outermost level, we can see the pattern defining the workflow of the application as a whole, with the model residing on the web server. At a smaller scale, the pattern is replicated within the client application and, at a smaller scale than that, within individual widgets in the client application. how these MVC patterns at different scales are nested within each other in the application architecture. So, what does this mean to us when we’re working on the code? In the following sections, we’ll take a more practical look at using MVC to define the structure of our JavaScript application, how it will affect the way we write code, and what the benefits will be. Let’s start with a look at the View. Licensed to jonathan zheng 124 CHAPTER 4 The page as an application 4.2 The View in an Ajax application From the position of the JavaScript application delivered to the browser when the application starts up, the View is the visible page, consisting of the DOM elements that are rendered by HTML markup or through programmatic manipulation. We’ve already shown how to manipulate the DOM programmatically in chapter 2. According to MVC, our View has two main responsibilities. It has to provide a visible interface for the user to trigger events from, that is, to talk to the Controller. It also needs to update itself in response to changes in the Model, usually communicated through the Controller again. If the application is being developed by a team, the View will probably be the area subject to the most contention. Designers and graphic artists will be involved, as will programmers, particularly as we explore the scope for interactivity in an Ajax interface. Asking designers to write code, or programmers to get involved in the aesthetics of an application, is often a bad idea. Even if you’re providing both roles, it can be helpful to separate them, in order to focus on one at a time. We showed in our overview of server MVC how code and presentation could become intertwined, and we separated them out using a template system. What are the options available to us here on the browser? In chapter 3, we demonstrated how to structure our web pages so that the CSS, HTML, and JavaScript are defined in separate files. In terms of the page itself, this split follows MVC, with the stylesheet being the View and the HTML/DOM being the model (a Document Object Model). From our current perspective, though, the page rendering is a black box, and the HTML and CSS together should be treated as the View. Keeping them separate is still a good idea, and simply by moving the JavaScript out into a separate file we have started to keep the designers and the programmers off each other’s backs. This is just a start, however, as you’ll see. 4.2.1 Keeping the logic out of the View Writing all our JavaScript in a separate file is a good start for enforcing separation of the View, but even with this in place, we can entangle the View with the logic roles (that is, Model and Controller) without having to try too hard. If we write JavaScript event handlers inline, such as The View in an Ajax application 125 then we are hard-coding business logic into the View. What is datafeed3? What does the value of mytextbox have to do with it? Why does importData() take two arguments, and what do they mean? The designer shouldn’t need to know these things. importData() is a business logic function. The View and the Model shouldn’t talk to one another directly, according to the MVC canon, so one solution is to separate them out with an extra layer of indirection.