Discussion Title : Cytoscape 3.0 View

Editor(s): SarahKillcoyne

<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>

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.

Required Features

Use Cases

Usecases showing that synchronizing state should be possible even for objects that don't share the same ViewModel:

State to be stored in ViewModel instances

Example Implementation of ViewModel and Presentation

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.



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. Note that this is just one possible way to handle view data in a way that supports the use cases presented thus far. Please offer up other proposals, alterations, thoughts etc.

Class Diagrams


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. As a quick note, views would not be required to publish their events so a basic view would be as simple as the SingleViewSequence diagram below minus the EventPublisher.


Sequence Diagrams

Single View

The basic case with a single view that is just publishing it's events, it is not handling events from any other view.


  1. The GraphView gets a user-initiated mouse event to change the color of a node to blue

  2. GraphView calls changeColor on the Controller (note the method name is dependent on what the ViewModel chooses to expose through it's controller)

  3. GraphController calls setColor on the GraphViewModel, the model updates it's mappings. The controller also publishes the color change event to the EventPublisher for any other Views to listen.

  4. The last step is debatable. The View could assume the controller has done it's work and refresh itself, if the ViewModel was correctly updated the View would also be updated. Alternately the Controller could publish a refresh event for the View to listen to. The updside is that the refresh would then not occur until it was sure the mappings had been changed on the ViewModel. The downside is that all views (models and controllers) would be required to use an EventPublisher and all views would have to implement a listener. While this is not hard it just adds a little more work for a plugin writer.

Multiple Views


This sequence describes the case where one view is listening for another view's events and updating accordingly. The sequence where a view is listening to other events:

  1. NodeController creates a listener for GraphSelectNodeEvents and registers that listener with the EventPublisher.

  2. User-initiated mouse event selects a node in the GraphView

  3. GraphView calls selectNode on the GraphController

  4. GraphController calls setSelected on the GraphViewModel (which updates it's mappings). The controller also creates a GraphSelectNodeEvent and publishes it to the EventPublisher then refresh is called on the GraphView (see the last step above).

  5. The EventPublisher then tells all listeners of the event to handleEvent().

  6. The listener.handleEvent() method registered in the first step calls on the NodeController to setSelected on the NodeViewModel then refresh the NodeView (again, see last step above).

  7. Now the NodeView mirrors the selection state of the GraphView.



Prototype Code

Checked in to http://chianti.ucsd.edu/svn/csplugins/trunk/isb/skillcoyne/view_cy3/ (This is not yet up-to-date with the latest network model)

(MikeSmoot) I've spent a fair amount of time studying this code and I think it's pretty reasonable. My only real concern is the controller and that it essentially duplicates the entire view_model interface. Why not just let the view_model fire it's own events? What is the advantage of having two classes instead of one since the two classes depend entirely on one another? Do we envision either the view_model or controller changing substantially? Another thought is that since the controller more-or-less just wraps calls to the view_model, why not make it an aspect?

Open Issues

Outdated_Cytoscape_3.0/ViewModelDiscussions (last edited 2011-02-24 15:33:21 by PietMolenaar)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux