164

CHAPTER 5

The role of the server

(in whatever server language) as following one of several architectural patterns. Let’s have a look at these now.

5.3 The big picture: common server-side designs

Server-side frameworks matter to all Ajax applications. If we choose to generate

the client code from a sever-side model, it matters a great deal. If we hand-code

the client code and serve it as static HTML and JavaScript pages, then the framework isn’t involved in delivering the app, but the data that the application will consume still has to be dynamically generated. Also, as we noted in the previous section, the server-side framework typically contains a domain model of some sort, and the presentation tier framework stands between that model and our Ajax application. We need to be able to work with the framework in order for our application to function smoothly.

Web application servers can be unkindly characterized as developers’ playgrounds. The problem of presenting a coherent workflow to a user through a series of web pages, while interfacing to back-end systems such as database servers, has never been adequately solved. The Web is littered with undernourished, ill-maintained frameworks and utilities, with new projects popping up on a monthly, if not weekly, basis.

Fortunately, we can recognize discrete families within this chaotic mixture. Reducing this framework soup to its essentials, there are possibly four main ways to get the job done. Let’s examine each in turn and see how it can be adapted to the Ajax model.

5.3.1 Naive web server coding without a framework

The simplest kind of framework is no framework at all. Writing a web application without a framework defining the key workflow elements, or mediating access to the back-end systems, doesn’t imply a complete lack of order. Many web sites are still developed this way, with each page generating its own views and performing its own back-end housekeeping, probably with the assistance of some shared library of helper functions or objects. Figure 5.2 illustrates this pattern of programming. Modifying this approach for Ajax is relatively straightforward, if we assume that the client is hand-coded. Generating client code from the server is a big topic that’s beyond the scope of this book. To deliver the client, we need to define a master page that will include any necessary JavaScript files, stylesheets, and other resources. For supplying data feeds, we simply need to replace the Licensed to jonathan zheng

The big picture: common server-side designs

165

Web browser

Web server

Helpers

Views/pages

Database server

Figure 5.2 Web programming without a framework. Each page, servlet, or CGI script maintains its own logic and presentation details. Helper functions and/or objects may encapsulate common low-level functionality, such as database access. generated HTML pages with XML or the other data stream of our choice (more on this topic later).

The key shortcoming of this approach in a classic web app is that the links between documents are scattered throughout the documents themselves. That is, the Controller role is not clearly defined in one place. If a developer needs to rework the user flow between screens, then hyperlinks must be modified in several places. This could