Cytoscape APIs
Cytoscape Provided Services
Plugin Implemented Services
The APIs for these services are defined as interfaces in Cytoscape. The interfaces are as follows:
- AlgorithmFactory/Algorithm
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); boolean isEnabled(context of some sort); } 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);
Menus
Menu Action flow of events
MenuItem is created.
- Click on a menu
The menuSelected() method checks the CytoscapeActionFactory metadata to see if the menu item should be enabled/disabled. The Action could just declare what attributes need to exist in the world in the metadata of the CytoscapeActionFactory. For example, you could define metadata like requiresNetwork, requiresNetworkView, requiresNodeSelection, requiresEdgeSelection, etc.. There could also a overriding metadatum called isEnabled that could be forced to be true if necessary.
- The menu would be displayed if the action is enabled.
The menu looks for a registered service for CytoscapeActionFactory. The individual factory returned is determined based on a parameter to the MenuItem. This happens dynamically based on how the CytoscapeActionFactories are defined.
- 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.
- The factory.createAction() method is called with all of the appropriate params (e.g. currentNetwork, currentNetworkView, etc.).
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.
Scripting
This Action model needs to be separated from the GUI so that it can be used in a scripting context (i.e headless mode) as well.
MetaData could also be used to specify where the Action can be used. For example you could set a requiresGUI (or even requiresSwing) element that would disable the action if the current running context doesn't support a GUI.
the Solution
[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.
General Bundle Organization
- Each service described below will consist of a small number of interfaces. All service interfaces will be part of a single framework bundle.
- Each service implementation will (probably) have a separate bundle. This isn't necessary, but some organization is a good idea.
- There will be an initialization bundle that will handle starting and stopping all of the core services defined in the framework.
- The GUI will consist of separate bundles.
- Each service will (for the most part) have an associated GUI bundle.
Breakdown of Cytoscape Services
Currently supported by Cytoscape.java.
- handled by OSGi
- void exit(int returnVal) {
- gui specific
CytoscapeDesktop getDesktop() {
VisualMappingManager getVisualMappingManager() {
- network service
- network view service
- Map getNetworkViewMap() {
CyNetworkView getNetworkView(String network_id) {
CyNetworkView getNullNetworkView() {
- boolean viewExists(String network_id) {
CyNetworkView getCurrentNetworkView() {
- boolean setCurrentNetworkView(String id) {
CyNetworkView createNetworkView(CyNetwork network, ...) {
void destroyNetworkView(CyNetworkView view, ...) {
- session service
- String getCurrentSessionFileName() {
- void setCurrentSessionFileName(String newName) {
- void setSessionState(int state) {
- int getSessionstate() {
- void createNewSession() {
- attribute service
CyAttributes getNodeAttributes() {
CyAttributes getEdgeAttributes() {
CyAttributes getNetworkAttributes() {
- void loadAttributes(String[] nodeAttrLocations, String[] edgeAttrLocations) {
- import service
No need to exist. Imports are handled automatically by getting service references to all CyNetworkFileFilters.
- event handling service
SwingPropertyChangeSupport getSwingPropertyChangeSupport() {
PropertyChangeSupport getPropertyChangeSupport() {
- void firePropertyChange(String property_type, Object old_value, Object new_value) {
- expression data service
ExpressionData getExpressionData() {
void setExpressionData(ExpressionData expData) {
- boolean loadExpressionData(String filename, boolean copy_atts) {
- ontology service
OntologyServer buildOntologyServer() {
OntologyServer getOntologyServer() {
- String getOntologyRootID() {
- void setOntologyRootID(String id) {
CyAttributes getOntologyAttributes() {
- bookmark service
- Bookmarks getBookmarks() throws JAXBException, IOException {
- void setBookmarks(Bookmarks pBookmarks) {
NOT Currently provided by Cytoscape.java
- Export service
- No need to exist. Imports are handled automatically by getting service references to all export filters.
"Services" currently existing elsewhere that would be transformed into OSGi services.
- Proxy handling service
- Layout service
- Web Service Service
Groups - Perhaps this should be integrated with CyNetwork and CyNetworkView. CyGroup should be in/related to CyNetwork (CyNode?) and CyGroupView should in/related to CyNetworkView (CyNodeView?).
Visual Styles
A VisualStyle consists of a NodeAppearanceCalculator, EdgeAppearanceCalculator, and GlobalAppearanceCalculator.
NodeAppearanceCalculators and EdgeAppearanceCalculators consist of lists of Calculator objects. Each calculator has a specific VisualPropertyType. Only one Calculator of a given VisualPropertyType is allowed in either NodeAppearanceCalculators or EdgeAppearanceCalculators.
Possible Improvements for VisualStyles
Get rid of the NodeAppearance and EdgeAppearance objects. Instead, operate directly on CyNodeView and CyEdgeView.
Get rid of NodeAppearanceCalculator and EdgeAppearanceCalculator and just let VisualStyle keep a list of the individual Calculators.
Make GlobalAppearanceCalculator based on VisualPropertyType. Perhaps with dummy calculators?
Re-enable applyVisualStyle to CyNetworkView instead of applying the visual style in the VisualMappingManager. This would have the advantage of allowing different implementations of views to handle different visual properties as they deem appropriate.
The Calculator objects must to be reworked to fetch attributes from CyAttributes rather than operating on their own attribute bundle model. The attribute in question should be an argument to the Calculator.
Consider getting rid of CalculatorCatalog. Calculators are small objects and there won't be that many of them any way.
- Perhaps consolidate Mapping and Calculator since Calculator really just passes a mapping value through to an Appearance.
Current Cytoscape Actions
- SHOULD be gui independent
ExportAction.java
- ExportAsGMLAction.java
- ExportAsXGMMLAction.java
ExportVizmapAction.java
ExitAction.java
CloneGraphInNewWindowAction.java // misnamed
DeselectAllAction.java
DestroyNetworkAction.java
NewWindowSelectedNodesEdgesAction.java // new NETWORK from selected
NewWindowSelectedNodesOnlyAction.java // new NETWORK from selected
ImportVizmapAction.java
NewSessionAction.java
OpenSessionAction.java
ProxyServerAction.java
SaveSessionAction.java
SaveSessionAsAction.java
- pops up dialog
MapOntologyAction.java
PluginManagerAction.java
PluginUpdateAction.java
PreferenceAction.java
PrintAction.java
HelpAboutAction.java
HelpContentsAction.java
BookmarkAction.java
- gui specific view manipulation
FitContentAction.java
HideSelectedAction.java
AlignVerticalAction.java
SelectAllAction.java
SelectAllEdgesAction.java
SelectAllNodesAction.java
ShowAllAction.java
UnHideSelectedAction.java
ZoomAction.java
ZoomSelectedAction.java
- gui specific state
SelectionModeAction.java
CytoPanelAction.java // pops up a cytopanel and takes a cyto panel type as arg
BirdsEyeViewAction.java
Algorithm Workflow
- Click Top-level menu
- Check algorithm meta data to see if menu item should be enabled.
- Click menu item.
MenuManager checks Algorithm meta data to UI service id.
MenuManager associates a GUI instance with an Algorithm through Algorithm meta data.
MenuManager creates a GUIController object that knows about the Algorithm and the GUI.
MenuManager creates GUI based on the UI service id. MenuManager creates the GUI with a GUIController object.
- GUI intializes itself from UI.getFallBackInterface().
- User does stuff to the GUI setting the various Tunables.
- User clicks submit().
GUI calls GUIController.execute(List<Tunables>).
- GUIController.close() gets called some point to close the GUI.
GUIController gets all associated algorithms with GUI and calls AlgorithmFactory.createAlgorithm(List<Tunable>).execute().