org.progeeks.util
Interface ViewContext

All Superinterfaces:

StandardBean

All Known Subinterfaces:

CloseableContext, FocusedContext, MultiFocusedContext, ObjectViewContext

All Known Implementing Classes:

ChartContext, DefaultMultiFocusedContext, DefaultObjectViewContext, DefaultViewContext, MetaPropertyContext

public interface ViewContext
extends StandardBean

Represents a section of the model operated on by a particular view and the view-specific model. This concept is sort of a merging of three different ideas:

• The Model-View-Controller Pattern (MVC)
• The Presentation-Abstraction-Control Pattern (PAC)
• My modified MVC: Model-(View+ViewModel+Controller)

In PAC, the interface is broken down as a series of agents each with their own presentation, abstraction, and control elements. The key point is that agents are represented in a hierarchy where each child is dependent and operates upon its parent. Controllers facilitate communication between the leaves, etc, etc..

In MVC, the model is the view-independent application data/operations upon which one or more views will operate. Typically, the view and controller are rolled into one. I would also argue that the "view" deserves its own model independent of the application model. This can also be another way of looking at the Controller I suppose. Swing does this frequently with things like ButtonModel, ListModel, etc. which are likely not directly represented in any sort of application model. Nor do I frequently find myself sharing them except in a few rare cases. It's almost always easier to hook them directly up to the application model piece that they represent and have one view-model per view.

In some cases, standardizing on a specific view-model idiom can be beneficial. Organized into a hierarchy, they give us similar benefits to a PAC agent except that control is somewhat inverted. Instead of having a hierarchy of self-contained agents, you have a hierarchy of view-organized model-contexts around which views/controllers are attached.

As an example, let's take an application window for a browser-like application. The main window has a title bar, a status bar, a menu bar, a tree panel on the left, and an object browser on the right. A possible context organization could be to have a window-specific context object that contains properties to represent the menu actions, status bar text, and selected object in the tree. Each component can listen to these properties as needed to determine their state.

In the above example, it might also be desirable to add a root context at the application level to hold shared model information. The root context may contain information about which window-specific context currently has the focus.

Each nested context will have a reference to its parent. This provides a dependency hierarchy similar to that of PAC. Occasionally, the parent may also contain a list of its contained contexts as may be necessary for its associated view/controller.

A more advanced example can be used for context-sensitive menus. The menu could have a menu-context associated with it the includes the currently operated-upon object. Each menu item (or action) can listen to the state of the menu-context. When a user right-clicks on an item, the controller can set the hit object in the menu-context before popping open the menu.

Version:

$Revision: 1.4 $

Author:

Paul Speed

Method Summary

ViewContext	getParentContext() Returns the parent context upon which this context depends, or null if this is a root-level context.
void	setParentContext(ViewContext parent) Sets the parent context of this context.

Methods inherited from interface org.progeeks.util.beans.StandardBean

addPropertyChangeListener, addPropertyChangeListener, hasListeners, hasListeners, removePropertyChangeListener, removePropertyChangeListener, removePropertyChangeListener

Method Detail

setParentContext

void setParentContext(ViewContext parent)

Sets the parent context of this context.

getParentContext

ViewContext getParentContext()

Returns the parent context upon which this context depends, or null if this is a root-level context.