Package org.scopemvc.core

The core package establishes the fundamental patterns for the MVC implementation in Scope through the definition of a limited set of interfaces and classes.

See:
          Description

Interface Summary
Controller Controllers arranged in a hierarchy of chains of command provide the structure of an application's logic, mirroring independent contexts of discrete Views and their bound model objects.
ModelChangeEvent Event that is broadcasted to notify interested ModelChangeListeners of a change in state of a model object implementing ModelChangeEventSource.
ModelChangeEventSource Implemented by model objects that fire ModelChangeEvents when their state changes: an implementation of the Observer Pattern.
ModelChangeListener A listener to the ModelChangeEvents fired by a model object implementing ModelChangeEventSource when it changes state.
ModelChangeTypes Constants for types of model change used in ModelChangeEvent.
PropertyView A View that can be bound to a property by specifying a Selector.
View A View implements the presentation of a model object to the user and allows interaction with the model object.
 

Class Summary
ActionManager ActionManager is a ModelManager that handles the actions (invokable methods) of model objects.
Control A token passed up the chain of Controllers to invoke a piece of presentation logic.
EditorManager EditorManager is a ModelManager that handles the creation of appropriate Viewer and Editor Views for the properties of model objects for a specific view type.
IntIndexSelector An implementation of Selector that identifies a property by its int index within the parent model object.
ModelAction Actions on model objects can be invoked via ActionManager's API, taking a ModelAction to describe the method to invoke.
ModelManager ModelManagers provide decoupled operations on model objects including access to properties and invocation of actions.
PropertyManager PropertyManager is a ModelManager that provides access to the properties of model objects.
Selector An identifier for model properties.
StringIndexSelector An implementation of Selector that identifies a property by its String index within the parent model object.
 

Exception Summary
ControlException Controllers throw ControlExceptions while responding to Controls if something goes wrong that must be reported to the user.
 

Package org.scopemvc.core Description

The core package establishes the fundamental patterns for the MVC implementation in Scope through the definition of a limited set of interfaces and classes. Most of core is not used by application developers who will instead build JavaBeans model objects and use the Swing Views defined in org.scopemvc.view.swing. However, an awareness of the interfaces and patterns in this package is useful when implementing an application using Scope.

The core MVC pattern implementation

Scope Components

The three fundamental components in Scope are:

Model

A model object represents an object in the application's "business domain", for example, a Product object in a sales application. A model can be implemented simply as a regular Javabean (with the default implementation). Scope accesses the properties of such a bean using the BeansPropertyManager, which will in turn use the Javabean APIs to invoke the model's public getters and setters when it needs access to the properties (for example when updating a View with the current state of the model to which it is bound).

The properties of a model are identified and accessed via Selectors: either with a string name or an integer index. This provides Scope with a generic, decoupled means to access the properties of model objects, although application code will usually use a model's public accessors directly.

A "active" model can implement the ModelChangeEventSource interface in which case it will fire events whenever its internal state changes. This allows (for example) a Swing GUI to automatically update to show the latest state of the models that it presents.

View

A View presents a Model (and its properties including submodels). For example, a Swing presentation within a JFrame, or an HTML page generated by a servlet.

Views can update the model to which they are bound so that the two are always automatically in sync as the user interacts with the GUI.

Views can also listen for ModelChangeEvents from ModelChangeEventSources bound to them so that they can update themselves to reflect the models as application logic changes their state. Not all Views can do this: for example, servlet generated HTML Views typically have no way of listening to models on the server. However, typical "desktop " Views such as Swing-based windows can keep themselves in sync with changing models automatically via this mechanism.

Views are owned and created by Controllers that implement the flow of an application. As the user interacts with the View, actions that interact with the application logic implemented in Controllers result in the issuing of a Control to the owning Controller.

Controller

Controllers implement the application logic of a system, for example the way the application moves from one screen to another. As such, Controllers typically create Views and the model objects they present in response to Controls that determine the application flow. Controls represent actions that influence the application flow. For example a LoginControl may attempt to authorise a user and on failure exit the application, while on success present the main application screen.

Controllers are arranged in a hierarchy with a root Controller invoked to start the application's flow, probably by creating appropriate child Controllers to handle areas of functionality (ie related Use Cases).



Copyright © 2000-2002 The Scope Team. All Rights Reserved.