AJAX In Action [71]
Geometry of keyboard 1
width: 536px;
height: 68px;
top: 24px;
left: 24px;
}
.sidebar{
Geometry of keyboard 2
width: 48px;
height: 400px;
top: 24px;
left: 570px;
}
The musicalKeys class defines the visual style common to all keyboards. toplong and sidebar simply define the geometry of each keyboard.
By refactoring our keyboard example in this way, we have made it possible to reuse the code easily. However, the design of the keyboard is partly defined in the JavaScript, in the makeKeyboard() function in listing 4.4, and yet, as figure 4.5
shows, one keyboard has a vertical layout and the other a horizontal one. How did we achieve this?
Licensed to jonathan zheng The View in an Ajax application 133 Figure 4.5 Our revised musical keyboard program allows the designer to specify multiple keyboards. Using CSS-based styling and the native render engine, we can accommodate both vertical and horizontal layouts without writing explicit layout code in our JavaScript. makeKeyboard() could easily have computed the size of the DIV that it was targeting and placed each button programmatically. In that case, we would need to get quite fussy about deciding whether the DIV was vertical or horizontal and write our own layout code. To a Java GUI programmer familiar with the internals of LayoutManager objects, this may seem all too obvious a route to take. If we took it, our programmers would wrest control of the widget’s look from the designers, and trouble would ensue! As it is, makeKeyboard()modifies only the structure of the document. The keys are laid out by the browser’s own layout engine, which is controlled by stylesheets—by the float style attribute in this case. It is important that the layout be controlled by the designer. Logic and View remain separate, and peace reigns. The keyboard was a relatively simple widget. In a larger, more complex widget such as a tree table, it may be harder to see how the browser’s own render engine can be coerced into doing the layout, and in some cases, programmatic styling is inevitable. However, it’s always worth asking this question, in the interests of keeping View and Logic separate. The browser render engine is also a Licensed to jonathan zheng 134 CHAPTER 4 The page as an application high-performing, fast, and well-tested piece of native code, and it is likely to beat any JavaScript algorithms that we cook up. That about wraps it up for the View for the moment. In the next section, we’ll explore the role of the Controller in MVC and how that relates to JavaScript event handlers in an Ajax application. 4.3 The Controller in an Ajax application The role of the Controller in MVC is to serve as an intermediary between the Model and the View, decoupling them from one another. In a GUI application such as our Ajax client application, the Controller layer is composed of event handlers. As is often the case with web browsers, techniques have evolved over time, and modern browsers support two different event models. The classic model is relatively simple and is in the process of being superseded by the newer W3C specifications for event handling. At the time of writing, however, implementations of the new event-handling model vary between browsers and are somewhat problematic. Both event models are discussed here. 4.3.1 Classic JavaScript event handlers The JavaScript implementation in web browsers allows us to define code that will be executed in response to a user event, typically either the mouse or keyboard. In the modern browsers that support Ajax, these event handlers can be assigned to most visual elements. We can use the event handlers to connect our visible user interface, that is, the View, to the business object Model. The classic event model has been around since the early days of JavaScript, and is relatively simple and straightforward. DOM elements have a small number of predefined properties to which callback functions can be assigned. For example, to attach a function that will be called when the mouse is clicked