A Mapbuilder configuration file closely follows the Model-View-Controller (MVC) design pattern. There are many descriptions of the MVC design pattern available; a brief description of it as it applies to Mapbuilder is provided below. It is a very useful design pattern for web applications because it provides good separation between the information content, the presentation of that information and the application state.
A Model represents the information of the application, typically in the form of an XML document retreived from a web service or in the the form of a static file at a URL. Models provide "get" methods to retrieve particular pieces of information or state and "set" methods to update the information and state of the model. When set methods are used, views are notified of the change by calling listeners that can be registered with the model.
A View is a representation of the information in a model. Views can register themselves with a model to be notified of changes in the model that may affect the view. This is typically using "listener" callback methods which are called for various event types. Views may also provide means to send user gestures (e.g. mouse clicks) to a controller. In Mapbuilder, views are called widgets.
A Controller translates interactions with the view into actions to be performed by the model. Controllers modify the information and state of a model. In Mapbuilder, views are called tools.
The separation of model and view allows multiple views to use the same model. Consequently, model components are easier to implement, test, and maintain, since all access to the model goes through these components. This also makes it easy to extend because you can simply write a view and some controller logic and wire them into the existing application.
Mapbuilder can dynamically retrieve and store many different models within the same web application. In order to provide some structure to the various models that can be realized, a model may contain an array of other models in a parent-child replationship. For example, a WFS DescribeFeatureType response model can be logically represented as a child of a WFS GetCapabilities model since they are initimately related.
In the Mapbuilder object-oriented design, models, widgets and tools are all realized as object instances in Javascript. The list of objects to be created and the relationship between them is specified in the configuration file. Properties are also optionally assigned to each object in the configuration file. The actual objects that mapbuilder supports and the properties that can be assigned to them is detailed in the Component register.