|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||||
See:
Description
| Interface Summary | |
| AspectModelListener | Interface for listeners of aspect model events. |
| DataModelListener | Interface for listeners of data model events. |
| DataViewFactory | An interface for a factory that creates data views and their graphic implementations. |
| GraphicView | A graphic serving as a proxy for a concrete implementation of an abstract data view. |
| Class Summary | |
| AbstractDataViewFactory | An abstract data view factory for non-nested whole models. |
| AllTests | |
| AspectModel | A data model representing a special data relationship amongst client models beyond the conventional relationship of a whole model and its constituent parts. |
| AspectModelFlag | A select flag identifying an interactor as a member of an aspect model (such as a graph path element). |
| AspectModelMonitor | Singleton (global) monitor for aspect models. |
| AspectModels | Deprecated. |
| DataFeedback | Constants and utilities intended for use by data visualization interactors in providing interaction feedback presentations. |
| DataModel | Data Model |
| DataModelMonitor | Singleton (global) monitor for data models. |
| DataModelTest | |
| DataUtils | Constants and utilities related to data visualization. |
| DataView | Abstract base class for the role of "view" in an MVC-based visualization of client data. |
| DataViewMonitor | Singleton (global) monitor for data view. |
| EdgeModel | A part model representing a data relationship between two or more (possibly identical) vertex models in a whole model (a hyper-edge). |
| ElementModel | A part model representing a data element in a whole model that has no data relationships (no internal topology). |
| GraphModel | A whole model whose data elements have data relationships (has an internal topology, such as a graph, tree, or list). |
| GraphModels | Constants and utilities related to graph-like models and their topology. |
| GraphModelTest | |
| GroupModel | A whole model whose data elements have no data relationships (has no internal topology, such as an unordered bag and set). |
| GroupModelTest | |
| ListModel | A graph model representing a list of entries. |
| NullGraphicView | A graphic view without a graphic presentation. |
| PartModel | An abstract data model representing a portion of client data comprising a whole model, and which has a distinct presence in the whole view. |
| PartModelField | |
| PartModelField.EventIn | |
| PartModelField.EventInOut | |
| PartModelField.EventOut | |
| PartView | A data view representing a view of a part model. |
| PortModel | A part model representing a connection point for edge models, such as on a vertex model. |
| SuperModel | A whole model that contains none or more whole models. |
| SuperModelTest | |
| TestAspectApp | Test app for aspect model display. |
| TestAspectApp.AddAspectAction | |
| TestAspectApp.RemoveAspectAction | |
| TestAspectInput | Interaction inputs for test apps. |
| TestClientAgent | |
| TestClientAgent.MsgGraphOpenRequest | |
| TestClientAgent.MsgListOpenRequest | |
| TestClientAgent.MsgTreeOpenRequest | |
| TestClientApp | Test client for displaying various views of graph models. |
| TestClientWindow | Destiny workstation root window. |
| TestGraphApp | Test app for list model display. |
| TestGraphModels | Utilities for building test data models. |
| TestGraphWindow | Window for list display. |
| TestGraphWindow.Extended | Graph window with a button to open a sub-window and create new graph models. |
| TestListApp | Test app for list model display. |
| TestListWindow | Window for list display. |
| TestListWindow.Extended | List window with a button to open a sub-window and create new list models. |
| TestNetApp | Runs TestClientApp and TestServerApp on the same host. |
| TestParityApp | Test app for parity model display. |
| TestServerAgent | |
| TestServerAgent.MsgGraphOpenResponse | |
| TestServerAgent.MsgListOpenResponse | |
| TestServerAgent.MsgSetClientDataCommand | |
| TestServerAgent.MsgTreeOpenResponse | |
| TestServerApp | Test server that creates and updates graph models on a client (see TestGraphClient). |
| TestServerWindow | |
| TestTreeApp | Test app for tree model display. |
| TestTreeWindow | Window for tree display. |
| TestTreeWindow.Extended | List window with a button to open a sub-window and create new list models. |
| TestViewInput | Interaction inputs for test apps. |
| TestViewWindow | Base class for data model view windows. |
| TestViewWindow.StatusBarUpdater | |
| VertexModel | A part model representing a data element in a whole model that has data relationships (has an internal topology), which are represented by edge models. |
| WholeModel | An abstract data model representing a meaningful and self-consistent set of client data suitable for viewing as a whole. |
| WholeModel.GlobalWholeTree | Global tree used for all whole model tree nodes. |
| WholeView | A data view representing a view of a whole model. |
Provides special purpose building blocks for 2D/3D visualization of generic data structures, such as graphs.
This package supports data visualization through using the model-view-control
(MVC) paradigm. Focus is on abstract model and abstract view support,
with control being left mostly to the gumbo.interact
package, and graphic implementation being left to the gumbo.graphic
package and others. A data model in this package is an abstract representation
of some client data, and a data view is an abstract representation of a
graphic implementation (a concrete or graphic view) displaying the data.
The models and views in this package serve as proxies for the client
data and graphic views they represent. As such, they are implemented
as classes and not as interface-class combinations. Furthermore,
the classes do not implement Delegatable, since they are not
intended as delegatable services.
To maintain model-view independence, a data model should never reference
a data view. Instead, a data view should reference one data model,
and a graphic view should reference one data view, with the graphic view
pulling client, model, and view information through the data view and its
data relationships. To minimize the coupling between the graphic
view and the client data, the scope of access to the client data should
be as limited and generic as possible, such as through proxies of or adapters
to the client data.
This package assumes that client data may exist in a JVM or network box
separate from the display (client data on the server box, data display
on the client box). This package is intended for use on the display
side of the system, with high bandwidth coupling between the graphic views
and their corresponding abstract models and views. If any client data
is required by the graphics, it must be included (in whole or in proxy form)
with the data models (and hence the need for a client ID to assess the
freshness of the proxy data and to associate it with the actual client data).
The attributes of this package are...
Several factors drive the manner of model and view creation in this package. In general, before layout of a whole view can commence, all model parts in the corresponding whole model must be accurately rendered by the part views. And, before a view can accurately render itself it must have a graphic implementation and, possibly, access to the client data it represents. As such, a view cannot exist without its graphic implementation and model, and a part (view or model) cannot exist without its whole (view or model). To satisfy these constraints factory methods and severe constraints on adding new parts are used throughout this package to assure that a part always has a whole ancestor, and that views always have a model and a graphic implementation. In order to allow the use of data model subclasses, the client is allowed to extend and instantiate data models; but, a data model can only be added to a part model tree if it not already in a tree (no parent or children).
To simplify package implementation and client use, data model and data
view sharing is not allowed. If the same client data is needed in
two different ancestor models, two different data models must be created.
For example, if the same client data, a data vertex, is used in a
graph model and in a model of a path through the graph, then separate models
must be used for the data vertex in the graph and path whole models. To
accommodate situations where the same client data is represented by two or
more abstract data models, data models are allowed to share client IDs.
Disposable interface.
Calling the dispose() method immediately removes a model
or view object from active use. This involves disconnecting the object
from any data dependences (links, trees, associations), removing the object
from any global maps, and marking the object as being disposed. Note
that Object.finalize() cannot be used for this since the time
of its execution is undefined. Once a data model or view has been disposed,
subsequent use will throw an exception.Abstract data models serve as generic proxies for the pieces of client
data they represent. Specialization in the data model class hierarchies
is motivated almost exclusively by what is significant for presentation
layout and rendering.
A data model, which derives from the abstract base class DataModel,
includes a client ID and client data. The client ID
uniquely associates the data model with the client data it represents. It
can be used by the system or client to assess the freshness of the data model,
and to provide tracability to the original client data should a proxy for
the client data be used in the model.
Client data is included in the data model for use by the graphic implementations viewing the model. Typically, graphic views need no client data or, if they do, only a small subset of the actual client data. In the latter case a proxy for or adapter to the client data can be provided to the data model (e.g. a string with a label, or a constant defining a data state). The client data provided to a data model should be considered as attributes of the data model that affect its visual presentation. Other aspects of the client data can be left out. In fact, the data models and views do not use the client data, only the graphic views, if at all. Furthermore, the type of the client data provided to a data model must match that expected by any graphic view that may use it.
The DataModel class maintains a global map that associates
client IDs with all active data models. To allow for the possibility
that multiple models may represent the same client data, and therefore
share the same client ID, the mapping returns a set containing the associated
model or models, if any.
Data models are divided into whole models and part models.
Whole models represent meaningful collections of client data
that can be viewed as a whole. This also means that all of the
parts in a whole model must be known and laid out together. Part models
represent components in a whole model that have a distinct presence in
the view presentation and, as such, are significant for view layout and
rendering.
Whole and part models live in separate trees that implement the composition
pattern. These trees are implemented through service delegation
provided by classes from gumbo.util. These services
are exposed indirectly to the client, through type-safe methods. The
abstract model base classes, WholeModel and PartModel,
provide only public read access to the model, with concrete subclasses
providing any write access. This allows subclasses to control the
structure of the whole and part model trees.
Data views serve as generic views of data models. Associated
with each data view is a data model and a graphic view, which is
the graphic implementation (concrete view) of the abstract view. Graphic
views are implemented via the gumbo.graphic package, which
insulates this package from graphics technology dependencies. Depending
on its needs, a graphic view may require a reference to its abstract data
view, with access from there to the view and model data structures and
the client data.
Like data models, data views are divided into whole views and part
views. Unlike data models, data views are not specialized
and are not nested. Instead, their associated data models provide
whatever specialization is needed for view layout and display.
The client forms model associations directly on the data models, not the views, since views of the models may not exist yet. Graphic views of the models are responsible for resolving any model associations and creating their visual presentation, perhaps with additional graphic views (e.g. text callouts). Typically, the system establishes view associations on graphic views automatically, as the graphic views are created.
|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||||