This page last changed on Oct 23, 2007 by scytacki.
A view has an OTViewContext. One OTViewContext is shared between sibling views.
It provides methods for:
- looking up a view service
- adding a view service
- unimplemented: getting a view by object
- creating a child view factory.
Parent views( views that have children views), should create a OTViewFactory instance to create their
children views. A parent view should use the same OTViewFactory instance for all of its children views, this
way all the children will have the same OTViewContext.
A parent view uses a OTViewFactory instance by
- extending AbstractOTJComponentContainerView and calling one of the createSubViewComponent methods
- using OTViewContext.createChildViewFactory()
- calling OTJComponentService.getViewFactory()
provides methods for:
- finding a view by object
- finding a component by object
This is used by a lot of the scripts and java code so one view can control another view without
going through the OTObjects.
It can be obtained through 2 ways:
- implementing OTJComponentViewContextAware
- calling OTJComponentService.getJComponentViewContext()
provides methods to instanciate OTJComponentView. These views require additional initialization over the
basic OTView, so this service takes care of that initialization.
it can be accessed:
- extending AbstractOTJComponentView and calling getJComponentService();
- getting the OTJComponentServiceFactory which is registered as a view service, and calling
createOTJComponentService, a view factory has to be passed in.
aware interface used to pass the OTJComponentViewContext to a OTJComponentView.
This api is redundant with the method getJComponentViewContext on the OTJComponentService interface.
A functional difference is that it saves the creation of the OTJComponentServiceImpl,
just to access the OTJComponentViewContext.
a factory service provided so OTJComponentService objects can be created by parent views and used to create their
children views. This was created because each parent view needs its own OTJComponentService instance. If
AbstractOTJComponentView extended then a parent view doesn't need to worry about this interface.
Currently this is used in only 7 framework classes. It is not used by any views besides the top level OTViewer.
This is a JPanel which contains, the JComponent returned by an OTJComponentView. In many cases it is unnecessary,
originally it contained the different accessor methods for things a view needed. But now views have the view context
and view factory for that. The one functionality that provides is the OTViewContainer functionality. To be a
proper OTViewContainer an implementer needs to be able to replace the object it is viewing with another one. In
most parent view cases this should be possible without maintaining the OTViewContainerPanel, but that needs to be
This is a way to modify the view entry and scroll bars of a child view.
It it can be used in many OTObjects that represent a container view. Like OTPlacementContainer or OTBorderContainer.
It has drawbacks. It cannot be used by an container object that expects a specific child OTObject.
When the child object is requested from the container object the OTViewChild will be returned instead of the child inside.
In OTCompoundDoc objects the viewid attribute can be used on the object reference to modify the viewid of a particular
The plan for the future is to support annotations on objects that will allow the view id and scroll bar settings to be specified.
Another option is to use css style selectors.
provides methods for OTJComponentView objects which are parents of other views. It provides convenience methods
for getting components from the children objects.
provides basic functionality for OTJComponentViews,
- reloading views when the view entry changes, this uses the viewContainer, so this is affected by the "updateable" container
- creating controller services, so the real object system can be used
- getting child components, these methods don't property setup up the view container so they should be used with caution
- storing the viewContainer.
interaface which provides methods:
- changing the current object,
- getting the parent container
- getting the updatable container
- reloading the view.
An OTViewContainer instance can be accessed:
- by implementing OTViewContainerAware
- extending AbstractOTJComponentView and calling getViewContainer()
a view uses this interface for gaining access to the view container of a view.
Marker interface that all views should implement, typically views implement this indirectly.
provides a few useful methods and fields for views.
implements OTViewContextAware, provides getViewContext so subclasses can access it.
creates and caches the viewFactory instance
Interface for views that provide JComponents. It currently has two methods:
Classes that implement this method are created by the OTViewFactoryImpl. This is mainly
called done by OTJComponentServiceImpl
Views can implement this interface so they know what the request viewEntry was. The actual
view entry can be different because the viewMode was set. The requested viewEntry can
be specified by the user explicitly or it could have been determined by matching the OTClass
to the objectClass of the viewEntry.
Currently this is only used by OTAuthorEmbedDefaultView
This is an OTClass that is used in a few cases:
- it is used to register a mapping between a OTClass and viewClass, with the top level OTViewFactory created by
- it is passed as an argument to the OTViewFactory so its viewClass is used for an object
- it can be extended and new properties added so a particular view can be configured. Examples of this are:
Aware interface so views can access the OTViewContext, the Abstract* classes take care of this.
Aware interface so views can access the OTViewEntry
Extension of OTView that has one method:
this returns a string of xhtml, which is the "view" of the object.