|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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 View s and their bound model objects. |
ModelChangeEvent |
Event that is broadcasted to notify interested ModelChangeListener s
of a change in state of a model object implementing ModelChangeEventSource . |
ModelChangeEventSource |
Implemented by model objects that fire ModelChangeEvent s when their
state changes: an implementation of the Observer Pattern. |
ModelChangeListener |
A listener to the ModelChangeEvent s 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 |
Controller s throw ControlExceptions while responding to Control s if something goes wrong that must be reported to the user. |
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 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
Selector
s: 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.
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.
View
s can also listen for
ModelChangeEvent
s
from ModelChangeEventSource
s
bound to them so that they can update themselves to
reflect the models as application logic changes their state.
Not all View
s can do this:
for example, servlet generated HTML View
s
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.
View
s are owned and
created by Controller
s that
implement the flow of an application. As the
user interacts with the View
,
actions that interact with the application logic
implemented in Controller
s
result in the issuing of a Control
to the owning Controller
.
Controller
s implement
the application logic of a system, for
example the way the application moves from
one screen to another. As such, Controller
s
typically create View
s and
the model object
s they present in
response to Control
s that
determine the application flow. Control
s
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.
Controller
s 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).
|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |