Public: Concord Software Projects : OTrunk notes for refactoring view services
This page last changed on Jul 16, 2007 by scytacki.
The current view service system has been getting hacked on additions for a few months now, and it is to the point where it should be refactored. It seems like there are several places where there are redundant references. And the mechanisms by which the view services get setup is looking fragile.
These notes are based on a slightly refactored version of the code which has not been checked in yet.
Each view should have:
Those three items can all be services or provided by services:
The current JComponent specific versions of this same functionality should be modified to use the more abstract version.
Currently the view services are maintained by instances of OTViewFactoryImpl
View services are looked up using an OTViewServiceProvider interface which a view can access by implementing the OTViewServiceProviderAware interface.
The OTViewServiceProvider interface is implemented by an OTViewServiceProviderImpl class inside of OTViewFactoryImpl.
The OTViewFactoryImpl supplies the viewServiceProvider during the initView method.
The main OTViewFactoryImpl is only instanciated in the registerServices call of the OTViewBundle class.
The viewFactory itself is added as a service to itself.
So views can access their viewFactory through the their viewServiceProvider.
The main use of the viewFactory is behind the OTViewContainerPanel. This is the class that most compound views use to display their children views.
The setCurrentObject method in OTViewContainerPanel indirectly calls getView on its viewFactory.
The OTViewContainerPanel now has a notion of being a topLevel container. In this case it maintains a shared controllerService for its view. The shared controller service is setup when the setOTViewFactory method is called on the OTViewContainerPanel.
the setOTViewFactory is called in 7 places. In several places the viewFactory set is from getChildViewFactory. This is how the caller can setup a nested set of services.
In the OTUDLSidebar case this nested factory is inside of another view so the service nesting matches the view containment hirearchy.
The OTViewContainerPanel also has the concept of parent containers. This is to support the new additions to the OTViewContainer interface that allows a view to look up the nearest "updatable" container. An updatable container is one whose current object can be changed or updated. This type of nesting of the containers is setup by the OTJComponentContainerHelper which knows about the current container and is used by objects to make sub containers.
Another key element is how the OTJComponentServiceFactory is used. Objects that need to make sub views use its createJComponentService method to make a "sub" component service. For one thing this alows the sub views to share a common OTJComponentViewContext so they can access their peers.
|Document generated by Confluence on Jan 27, 2014 16:52|