3.2. Design Patterns and Object-Oriented MVC
In a fully MVC framework, views are observers of controllers and models, and models are observers of the controller. Okay, so you might be asking us, "What exactly does it mean for a view to be an 'observer of the model?'" Well, this is "design pattern speak" for saying that the view either subscribes to the model so that it can be updated whenever the model is changed, or that it polls the model periodically for updates and changes when that happens.
Perhaps you are asking yourself why all this stuff about MVC is important. Will it help me build better applications or help me impress Jenny from marketing?
It might. You'll be able to build more-robust applications, with better separation of concerns, so that when Jenny asks you to make a change to the layout on one of your pages, you'll be able to do it without fear that you might screw up your database.
When we say that a view is an observer of the model, it means that your models don't have to know anything about the views and how they work. So, they are totally disconnected from any change in the way the data is presented to the user. This is important in web applications because the "look and feel" is more likely to change than the underlying domain model, and so it is easy to update the things that you are most likely to update. Therefore, you can easily respond to the new girl in marketing's request to make the web interface look more appealing (all while you are totally relaxed with absolutely no worries that you are going to break your mission-critical model code on the back end).
Likewise, the controller gets called when a user clicks a link or a submit button on one of the views. This action causes an HTTP Post or HTTP Get message to be sent to the server. That message is then trapped by TurboGears, which in turn calls a controller method. That method takes the input that it is given, publishes a change to the necessary model objects, and then passes everything to a view, which displays a new page for the user.
One of the keys to making this architecture work is that models, views, and controllers have a "look but don't touch" rule; views aren't allowed to change models, controllers aren't allowed to change views, and models don't know anything about controllers or views and are merely changed by the various controller objects and published to views. This means that the scope of any given change is limited by the MVC pattern:
With MVC, you can change which data is presented in a view and the way that it is presented without the need to rewrite any model or controller code.
With MVC, you can change the way you react to a specific user action, without the need to rewrite any model or view code.
A Brief History of MVC
Web application development has come a long way in the past 10 years. It used to be that we used standard CGI and wrote a separate program to process every form. Most of our application code involved parsing request strings and using string concatenation to spit HTML output back to the user. This took forever to write, and ran slowly because we had to start up a new process for every request!
Then came ASP, PHP, and ColdFusion, which allowed us to have a single server process that took client requests to a specific URL and grabbed the corresponding file with HTML and embedded code, processed the code, and returned the resulting HTML. This was easier to write because generally there was more HTML than code, so it was easier to embed the code in the HTML rather than the HTML in the code. And it performed a lot better because everything ran in a single process, and you could cache database connections.
Then along came JSP, with Java servlets, which allowed "business logic" to be separated from "presentation logic" so that JSP pages could focus just on presentation and servlets could do everything else. This was a lot more maintainable, although people still tended to put too much code into the JSP presentation side of things, because it was a lot easier than writing a new servlet.
Then somebody remembered that this kind of problem had already showed up in the 1970s when people from Xerox Parc were inventing the modern GUI. In 1978, Trygve Reenskaug, along with a number of others at Parc, designed something called model-viewer-controller into the first object-oriented Smalltalk GUI. The theory behind MVC eventually made its way into Objective-C by 1986. Then, just after the original Macintosh computer was released, and the GUI was starting to take off, MVC received its first in-depth coverage in the book Object-Oriented Programming: An Evolutionary Approach by Brad J. Cox and Andrew J. Novobilski (Addison-Wesley, 1986).
Finally, MVC made its way to the Internet via WebObjects, and was popularized by Java Struts. You don't need to know all this history to use TurboGears; but if you lived through some or all of this, you should know that TurboGears strips away a lot of the verbosity and configuration requirements of web frameworks such as Struts, to make the MVC architecture easy to use.
With MVC, you might have to update one or more views when you change a model, because as an observer, views are still users of the model application programming interface (API).
But with MVC, you probably won't have to create new controller code unless that model change is connected to new or changed user actions.