Diff for "Outdated_Cytoscape_3.0/CommandDiscussions"

Differences between revisions 7 and 19 (spanning 12 versions)

(This page is under construction)

Command Layer Definition

Command layer contains mechanism to make Cytoscape functions easily accessible from application layer. This layer should be separated from application layer and can be used in any mode: Desktop application, server version, and command line version.

Requirements

Command layer should be separated from application or UI.
Commands should be accessible from scripting (dynamic) languages.
Should be manageable by Undo manager (in application layer).
Extensible. Plugin writers and developers use Cytoscape as library can add their own commands.

Command Usecases

From Plugins or Other Pre-Compiled Programs

From Interactive Shells

From Scripting Languages

Multiple Language Support

Commands should be easily accessible from dynamic (scripting) languages, including Python, Ruby, and JavaScript.

Functions Encapsulated as Command

In general, most of the classes in cytoscape.actions will be converted into Commands. In addition, some of the methods under the class cytoscape.Cytoscape will be encapsulated as command. Such as:

createNetwork()
createNewSession()
getNetwork()

Design

attachment:commandLayer1.png
Each command will be represented as an OSGi service.
Command executes the function through the OSGi service registory.
For easy access to commands, an utility class CommandService will be used.

// Java
CommandService.getCommand("command_name").execute();

// Ruby
CommandService.getCommand("command_name").execute

We can use similar design to Felix ShellService:

package org.apache.felix.shell;

public interface ShellService
{
    public String[] getCommands();
    public String getCommandUsage(String name);
    public String getCommandDescription(String name);
    public ServiceReference getCommandReference(String name);
    public void executeCommand(
        String commandLine, PrintStream out, PrintStream err)
        throws Exception;
}

Implementation

All commands should implement the following interface:

All command developer should implement this interface:

public interface Command {
        
        public String getName();
        public String getDescription();
        
        public List<Object> execute(List<Object> args, List<Class<?>> argTypes) throws Exception;
}

In most cases, command developer can extend this super class. Validation of the arguments (parameters) should be done by private method implemented by the command developer.

public abstract class AbstractCommand {

        private String name;
        private String description;

        // Arguments will be stored in this data structure.     
        private Tunable arguments;
        
        public AbstractCommand(String name, String description) {
                this.name = name;
                this.description = description;
        }

        public String getDescription() {
                return description;
        }

        public String getName() {
                return name;
        }

        public List<Object> execute(List<Object> args, List<Class<?>> argTypes) throws Exception {
                if(validate(args, argTypes) == false) {
                        throw new Exception();
                }
                
                List<Object> result = new ArrayList<Object>();
                
                // Execute.  If necessary, put the result to the list.
                
                return result;
        }
        
        private Boolean validate(List<Object> args, List<Class<?>> argTypes) {
                // Validate parameters
                
                // Then set parameters to Tunable.
                return true;
        }
}

Open Questions

What's the best parameter set for execute() method? Array of String/Object?
Return data type. Is List of Objects too general? Do we need name-value pair (i.e., Map) instead of value only List?

Actual implementation of the Command looks like the following:

public class ImportGraphFileCommand extends AbstractCommand {
    // Wrapping CytoscapeActions with Command
}

Exporting OSGi Service by Spring-DM

If we use one command = one OSGi service style design, we can use [http://www.springframework.org/osgi Spring Dynamic Module] for managing service import/export.

<bean name="importGraphFileCommandService"
                class="org.cytoscape.command.impl.ImportGraphFileCommandService" />

<osgi:service auto-export="interfaces" ref="importGraphFileCommandService" />

And Command Manager will be a class to holds a OSGi Service Tracker:

public final class CommandManager implements BundleActivator {

        private ServiceTracker commandServiceTracker;

        public Command getCommand(final String commandName){
            //returns the command using Service Tracker
        }

        public void start(BundleContext bundleContext) throws Exception {
                commandServiceTracker = new ServiceTracker(bundleContext, Command.class
                                .getName(), null) {
                        @Override
                        public Object addingService(ServiceReference serviceReference) {
                                Command command = (Command) super.addingService(serviceReference);
                                return command;
                        }
                };

                commandServiceTracker.open();
                
        }

        public void stop(BundleContext bundleContext) throws Exception {
                commandServiceTracker.close();
        }
}

References and External Links

OSGi Service

[http://neilbartlett.name/downloads/preview_intro_services.pdf Introduction to Services]
[http://www.knopflerfish.org/osgi_service_tutorial.html OSGi Service Tutorial]
[http://felix.apache.org/site/apache-felix-shell-service.html Felix ShellService]

Dynamic Language Support on JVM

[http://www.jython.org/Project/index.html Jython]
[http://jruby.codehaus.org/ JRuby]
[http://www.mozilla.org/rhino/ Rhino (JavaScript)]

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

-  ← Revision 7 as of 2008-05-31 00:05:18 →
  Size: 2806
  Editor: KeiichiroOno
  Comment:
+  ← Revision 19 as of 2008-06-04 18:02:19 →
  Size: 5855
  Editor: KeiichiroOno
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 7:
-== Requirments ==
+== Requirements ==
 Line 13:
-==== Multiple Language Support ====
+=== Command Usecases ===



==== From Plugins or Other Pre-Compiled Programs ====





==== From Interactive Shells ====

==== From Scripting Languages ====





=== Multiple Language Support ===
-Line 15:
+Line 24:
-Line 60:
+Line 70:
+All commands should implement the following interface:



 * All command developer should implement this interface:
-Line 61:
+Line 74:
-public interface Command

{

    public String getName();

    public void execute(Object[] args);
+public interface Command {

   public String getName();

 public String getDescription();

 

 public List<Object> execute(List<Object> args, List<Class<?>> argTypes) throws Exception;
-Line 68:
+Line 83:
+ * In most cases, command developer can extend this super class.  Validation of the arguments (parameters) should be done by private method implemented by the command developer.
-Line 69:
+Line 86:
-public class ImportGraphFileCommand extends Command {
+public abstract class AbstractCommand {
-Line 71:
+Line 88:
+ private String name;

 private String description;



        // Arguments will be stored in this data structure.	

 private Tunable arguments;

 

 public AbstractCommand(String name, String description) {

  this.name = name;

  this.description = description;

 }



 public String getDescription() {

  return description;

 }



 public String getName() {

  return name;

 }



 public List<Object> execute(List<Object> args, List<Class<?>> argTypes) throws Exception {

  if(validate(args, argTypes) == false) {

   throw new Exception();

  }

  

  List<Object> result = new ArrayList<Object>();

  

  // Execute.  If necessary, put the result to the list.

  

  return result;

 }

 

 private Boolean validate(List<Object> args, List<Class<?>> argTypes) {

  // Validate parameters

  

  // Then set parameters to Tunable.

  return true;

 }
-Line 74:
+Line 128:
-{{{
+===== Open Questions =====

 * What's the best parameter set for ''execute()'' method?  Array of String/Object?

 * Return data type.  Is List of Objects too general?  Do we need name-value pair (i.e., Map) instead of value only List?
-Line 76:
+Line 132:
+Actual implementation of the Command looks like the following:



{{{#!java

public class ImportGraphFileCommand extends AbstractCommand {

    // Wrapping CytoscapeActions with Command

}
-Line 80:
+Line 142:
+If we use one command = one OSGi service style design, we can use [http://www.springframework.org/osgi Spring Dynamic Module] for managing service import/export.



{{{

<bean name="importGraphFileCommandService"

  class="org.cytoscape.command.impl.ImportGraphFileCommandService" />

}}}



{{{

<osgi:service auto-export="interfaces" ref="importGraphFileCommandService" />

}}}



And Command Manager will be a class to holds a OSGi Service Tracker:



{{{#!java

public final class CommandManager implements BundleActivator {



 private ServiceTracker commandServiceTracker;



        public Command getCommand(final String commandName){

            //returns the command using Service Tracker

        }



 public void start(BundleContext bundleContext) throws Exception {

  commandServiceTracker = new ServiceTracker(bundleContext, Command.class

    .getName(), null) {

   @Override

   public Object addingService(ServiceReference serviceReference) {

           Command command = (Command) super.addingService(serviceReference);

    return command;

   }

  };



  commandServiceTracker.open();

  

 }



 public void stop(BundleContext bundleContext) throws Exception {

  commandServiceTracker.close();

 }

}

}}}