The model is a container for the components on a canvas. The model also stores other visual information about the canvas, such as the page settings and background color. The model acts as the target for commands and supports undo and redo capabilities. When a command is executed, it performs one or more actions on the model by calling methods in the model. After a command is executed, the model stores it in the transaction model.
Models share many of the same characteristics as components, so the CODModel class derives from CODComponent. The CODModel class is a visual component that contains other visual components. Components and models share the same composite interface for adding and removing child components. Like components, models can also have properties. Another consequence of models being components is that models can be nested.
MVC models that contain visual data are referred to as presentation models and have characteristics that are slightly different from system models. A system model contains strictly non-visual data that is rendered by one or more viewports. A presentation model contains visual data and is responsible for rendering that data onto a display surface. Frequently, presentation models have a subject-observer relationship with a system model in which the presentation model observes the system model. In other words, the presentation model is both a subject and an observer.
For example, you might have a model that displays information contained in a database. Each visual component in the model might represent a record in the database. The CODModel object can be setup to act as an observer of a separate system model, which encapsulates the non-visual information contained in the database. When records in the database are modified through the system model, the system model sends a notification to its observers. The CODModel object receives this notification and has the chance to update the canvas accordingly.
Setting up a subject-observer relationship between an Objective Views model and a system model is optional and is easy to do. Just mix-in the IObserver interface into your CODModel derived class and override the OnUpdate() method. Create a system model class derived from MvcModel. Then add instances of your CODModel derived class (your presentation model) as observers to your system model.
A component is a visual object that can be placed on a canvas. Anything that can be placed on a canvas and manipulated is a component, including links.
Because it contains visual information, the CODModel class derives from CODComponent. The CODComponent class supports nesting of components, so a component may have any number of child components. The model stores the components on the canvas as child components using the mechanism provided by CODComponent.
The model supplies a comprehensive set of methods that you can use to manipulate the components on the canvas. You can edit any aspect of a component via the model. For example, you can change the appearance of the component's lines, fill, font, position and more. If you want to manipulate the model programmatically, use these methods. The command objects use these same methods to respond to user interaction.
The model holds a map of unique IDs that map to component objects. When you add a new component to the model, a new ID is randomly generated. The model implements the IODComponentID interface, which defines some standard methods for generating these IDs.
If you would prefer some other scheme for generating IDs, override the CreateUniqueID() method.
Each model contains a transaction model, which supports the undo/redo capabilities of Objective Views. The transaction model logs the CODCommand objects that are created when the user performs an action on the canvas. They can be undone in order. For more information regarding CODCommand, see Section 12.7, "Command Classes."
The canvas background color and appearance is maintained by the model. You can define a background component or use the background color. By default, the background color is white, but you can change it to any color you wish.
The background component is any CODComponent that you would like to appear behind the other components on your canvas. You can create the background in Symbol Designer or load a pre-existing background, such as a bitmap.
You can drag a component from one canvas to another. To manage this activity, a model needs to know whether it is the source of a drag and drop operation or the target. CODModel contains a pair of Boolean values that manage this status.
The selected page settings determine how the model is printed. Information such as the units of measure, the size of the paper, and the margins is stored in the model as well. A class named CODPageSettings manages this information.
A model knows when it has been changed. Its state is reset whenever the model is serialized.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and Stingray, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.