OSGI_Refactoring_Possibilities

Cytoscape APIs

• CyNetwork

• CyNetworkView

• CyNode

• CyNodeView

• CyEdge

• CyEdgeView

• CyAttributes

Cytoscape Provided Services

Plugin Implemented Services

The APIs for these services are defined as interfaces in Cytoscape. The interfaces are as follows:

• GraphFileFilter

• CyLayoutAlgorithm

UI Services

Interactive - provide an option to bring up before or after action has run Action to create panel Action to be triggered by the panel

• Control Tab
• Results Tab
• Dialog

// the service interface
interface UIPanel {
  JPanel getJPanel();
}

// in the plugin
// meta data defining where/how to use the panel
Hashtable dict = new HashTable();
dict.put("panel.location","control");
dict.put("panel.name","hello world");
dict.put("service.pid","myuipanel.persistent.id");

bundleContext.registerService(UIPanel.class.getName(), new MyUIPanel(), dict);

Single Action

• Menu Item
• Button On Toolbar

// The factory is the service.  The factory will return individual action objects
// that can store internal state.  If we didn't have a factory, then the individual
// actions wouldn't be able to store their state because they'd persist as services.
interface CytoscapeActionFactory {
  CytoscapeAction createAction(context of some sort);
  List<Tunable> createParameters(possibly some context);
}

interface CytoscapeAction {
   void run();
}

// meta data defining where/how to use the action
Hashtable dict = new HashTable();
dict.put("preferred.menu","whereever/submenu");
dict.put("action.panel","myuipanel.persistent.id"); // so that it can get the exact panel
dict.put("menu.label","asdfasdf");
dict.put("icon", new Icon("my.png"));

bundleContext.registerService(CytoscapeActionFactory.class.getName(), new MyCyActionFactory(), dict);

Menu Action flow of events

1. Click on a menu

2. menu actionPerformed looks for registered service for CytoscapeActionFactory. The individual factory returned is determined when the menu is created. This happens dynamically based on how the CytoscapeActionFactories are defined.

3. First call createParameters() that creates some sort of UI (e.g. a GUI that allows input values or a command line that reads a config file or queries a database or reads a command line, etc.). This data is specified by the user and is then passed into the action that is created next.
4. The factory.createAction() method is called with all of the appropriate params (e.g. currentNetwork, currentNetworkView, etc.).

5. The CytoscapeAction object can now be run at your leisure.

CytoscapeAction can implement additional interfaces, e.g. ProgressTrackable, which would mean a progress monitor could be added.

A CytoscapeAction needs it's basic inputs (current network, current view, or possibly a DataManager), but it also may need separate parameters. These should be defined as some sort of Tunable or List<Tunable> or a JPanel that returns some sort of configuration object, e.g. a Dictionary of key -> value pairs.

The action context could be a DataManager interface that provides methods like getCurrentNetwork, getCurrentNetworkView, etc.. Alternatively, you could provide an Context object (e.g. CIShellContext) which could provide access to all Cytoscape services. This isn't an osgi context that worries about bundles, but is an application specific context that provides services appropriate for how the application is currently being run.

[http://cishell.org CIShell] does all of this now.

Action Services

• An action gets current context (network, view, etc.). Then the action does "something". The action should be independent of the UI. Make the actions chainable.