Professional Cairngorm™

23.1. The Problem

In earlier versions, the registration, adding of posts, and commenting features all required that certain things happen after certain procedures were performed. For example, the forms had to be cleared and the buttons enabled if an operation was successful. In other words, your views needed to be able to react to the status of procedure calls beyond simply displaying data held in the ModelLocator.

In the current version of the project you arranged this by binding to variables on the ModelLocator that indicated the success or failure of the request. However, as with most things, there is more than one way to notify views of the status of a procedure call. That being said, since you are using a framework that is based on the MVC paradigm, there are a few requirements you need to meet when doing so.

When you use the MVC paradigm, the control and model layers of the framework should not have to know anything about the implementation of the views. Requiring knowledge of a view's implementation increases the coupling between objects and gets complicated when multiple views need to react to the same procedure in different ways.

The binding of setter functions to properties on the model satisfies the requirement that the model and the control layer have no knowledge of what functions are being called on the view, or even what views are listening for the changes. The model has no idea who is binding to the status properties, and the command classes simply update the properties ...