Scripting in Bioclipse 2

From Bioclipse
Jump to: navigation, search
Development tutorial
Responsible author:Masak
Bioclipse version:2.X
".X" can not be assigned to a declared number type with value 2.
Last updated:2009-10-30

Bioclipse 2 contains scripting consoles, one for each supported scripting language. These consoles give the user access to data and plugins through a command-oriented environment.

Currently supported scripting languages are JavaScript, R, Groovy and Ruby, although the latter two have been disabled for the 2.0 release.

Short Guide

The JavaScript console takes up the space directly below the editor. It's open by default in Bioclipse, but should it be closed for some reason, you can re-open it through Window > Show View > Other... > Scripting > JavaScript Console".

Try typing in

2 + 2

at the console. You should be getting this back:

> 2 + 2

Now, press the <code>Tab key twice. A list of commands should appear. Try

help js

and you'll get a summary of the js:

> help js
Controls access to the Javascript Console.

 This manager has the following methods:
print( String message )
delay( int seconds  )
eval( String command )
say( String message )
executeFile( String filePath )

You can also write

help js.say

and get this description of the manager method js.say:

> help js.say
js.say(String message)
Prints a message to the console, adding a trailing newline.

Now, try typing cdk.fromSM, and have the console complete the method name by hitting the Tab key. The result should be this:


You get an opening parenthesis, because this is a method call. If the method expected no parameters, you'd get a closing parenthesis too. But here, let's provide a SMILES string:


The result is this:

> cdk.fromSMILES("CCCC")

If you want to store the molecule for later, you can assign the result to a variable:

var butane = cdk.fromSMILES("CCCC")

General idea of script support

Most functionality could be made available to input as scripting commands in a console. GUIs should merely collect data and call on one/many commands. This ensures clear separation between code, scripting, and the GUI. This also allows for recording of screen activities into a script to automate tasks.

The idea is that you are able to work your way towards a final script by using the GUI. In real research, you don't know where you'll end up from the start. If you, for example, query a database for something unknown you have no idea what you expect as results or how many results you will get. If you adjust your filters iteratively until you get the subset of the results, you end up with a small sequence of scripting commands, that can serve as one step in your project/analysis. Then you can look at the problem from a different viewpoint, maybe a new database. After you find out what information you want from it, you copy those scripting commands to the script. Now you have data resources that you can integrate. The point is, with a work-flow system it would not have been feasible to construct such a work-flow, since it was developed iteratively with user curation at a number of steps.