Cytoscape WikiDiscussion Title : Cytoscape 3.0 View |
Editor(s): SarahKillcoyne |
--- DOCUMENT IN PROGRESS 2007-12-10 ---
About this document
In discussions between Mike and Sarah during the repackaging of the current Cytoscape it was determined that we needed to do some significant work to separate model from the view. Several requirements have fallen out of various discussions that these class diagrams should help clarify and hopefully address.
- Each network can have any number of views
- A view may need to share the visual state (selection, color, etc) of any other view
- View data should be persistable (IO needs access in order to save it in a session/project file)
- Plugins need to be able to create their own views and their view data should also be persistable
General Notes
Initially we need to add another package for a ViewModel (see NewPackageStructure.jpg). These can contain whatever mappings we need for color, selection, location, and any other persistable display type information. The IO package would have a dependency now on both the Model and the ViewModel packages (separating them to keep clear what data goes where). On top of this ViewModel is a Controller that will do a couple of things: 1) Make the calls to the ViewModel to change it’s mappings 2) Publish these calls as events (selectionEvent for instance) for other view’s controllers to listen to 3) Register interest in other view controllers events. The controller becomes basically the public API to the underlying model. The reason for this is to keep logic out of the data objects, so the controller can handle any necessary logic.
On the presentation side (org.cytoscape.view module) has a View interface. The View will make calls on it’s Controller to change the underlying ViewModel. This should make it fairly easy to switch out presentation layers without having to change how the models behave. In this way IO will only have to deal with the model layer, but the model layer will have all necessary data.
attachment:NewPackageStructure.jpg
References
I have put together several class and sequence diagrams, mainly to help visualize the flow of data and some prototype code to follow that flow.
Class Diagrams
attachment:MVC_interface.jpg
This diagram is just an example at the class level of the dependencies. A View (GraphView/NodeView) is the presentation layer model, it depends on both a Network model (CyNetwork) and a ViewModel (GraphViewModel/NodeViewModel). The models each hold just the mapping data (what nodes are selected, what nodes are colored blue or red, etc). Each view would then have it's own controller. The controller can be thought of as the publically accessible API of the model that handles any actual logic, especially concerning events that the View may want published/handled. The controllers would all depend on a single EventPublisher class that handles registering listeners and propagating events to those listeners.
attachment:MVC_class.jpg
Sequence Diagrams
attachment:SingleViewSequence.jpg The basic case with a single view that is not publishing it's events or listening for events from any other view.
attachment:MultiSameViewSequence.jpg This describes the case of two of the same type of view (both graph views in this case) publishing and listening to each other's events. Although it appears a little ugly there's a fairly simple progression that each mirrors. (desc steps here...)
attachment:AdaptorSequence.jpg This sequence merely separates out the listener (Adaptor) part that in previous sequences lived in the Controller. This mostly helps to keep the Controller class clean and free from any ugly logic that may be required to match up two views.