Difference between revisions of "Script Parameters"
(→Parameter properties) |
(→Basic syntax: Clarify some parameter behavior) |
||
Line 29: | Line 29: | ||
</source> | </source> | ||
− | We see that an input parameter <code>name</code> of type <code>String</code> is declared. | + | We see that an input parameter <code>name</code> of type <code>String</code> is declared. <code>@arameters</code> are handled automatically by the framework; if we run this script when the User Interface is available (e.g. from the script editor), the <code>name</code> parameter will automatically be harvested via a pop-up dialog: |
− | |||
− | + | [[File:ScriptParams.png|450px]] | |
− | |||
− | |||
− | |||
− | |||
− | # | + | We could also run this script [[Headless#Running_scripts_in_headless_mode|headlessly]], thanks to the general nature of <code>@parameters</code>. |
− | + | ||
− | + | When the script is completed, any <code>@OUTPUT</code> variables are handled by the framework, based on their type. In this case we expect the <code>greeting</code> variable to be printed, since it is a <code>string</code>. | |
− | |||
− | |||
− | |||
− | + | {{Warning | Note that if we added an extra comment to the top of our script we would break the script, as the parameters would not be harvested or displayed due to violation of the second parameter rule: <source lang="python"> | |
+ | # Because of this comment, the following parameters will NOT be recognized | ||
+ | # @String name | ||
+ | # @OUTPUT String greeting</source>}} | ||
== Parameter properties == | == Parameter properties == |
Revision as of 09:41, 18 March 2016
Contents
All scripting languages have access to a universal @parameter
notation for declaring inputs and outputs. This approach is preferred to using ImageJ 1.x GenericDialog
because it is totally agnostic of the user interface, allowing such scripts to run in a variety of contexts. As with ImageJ2 plugins, script parameterization is based on the SciJava @Parameter annotation - so experience with plugin writing directly translates to scripting, and vice versa.
Basic syntax
The rules for @parameter
use are as follows:
- All parameter declarations must appear in comments. Each comment line contains a single parameter declaration and nothing else.
- Any parameters after the first non-parameter line will not be recognized.
@type variableName
will declare an input of the indicated type, assigned to the specified name.@OUTPUT type outputName
will declare the variable of the specified name as an output parameter with the given type.
For example, if we look at the Greeting.py template supplied with Fiji:
# @String name # @OUTPUT String greeting # A Jython script with parameters. # It is the duty of the scripting framework to harvest # the 'name' parameter from the user, and then display # the 'greeting' output parameter, based on its type. greeting = "Hello, " + name + "!"
We see that an input parameter name
of type String
is declared. @arameters
are handled automatically by the framework; if we run this script when the User Interface is available (e.g. from the script editor), the name
parameter will automatically be harvested via a pop-up dialog:
We could also run this script headlessly, thanks to the general nature of @parameters
.
When the script is completed, any @OUTPUT
variables are handled by the framework, based on their type. In this case we expect the greeting
variable to be printed, since it is a string
.
Parameter properties
If you look at the @Parameter annotation, you will notice it has many properties - for example, name
and description
.
Script parameters can set these properties, following these guidelines:
- All properties are defined in a single parenthetical expression immediately following the
@Type
declaration. - Properties are set by a comma-separated list of key=value pairs
Properties are your way to give hints to the framework how a given parameter should be handled.
Widget labels
Widgets are the User Interface elements shown to users to collect input information. For example, instead of just displaying "Name" to the user, we can add a custom label to the field of our Greeting.py
script as follows:
# @String(label="Please enter your name") name # @OUTPUT String greeting greeting = "Hello, " + name + "!"
Widget mouseover
We can add a description
property to provide mouse-over text for our field:
# @String(label="Please enter your name", description="Your name") name # @OUTPUT String greeting greeting = "Hello, " + name + "!"
Default values
Default values are also supported as parameter properties:
# @Integer(label="An integer!",value=15) someInt
Files and Folders
By default, a `@File` parameter will create a chooser for a single file:
# @File(label="Select a file") myFile print(myFile)
If you want to select a directory instead, use a style
property:
# @File(label="Select a directory", style="directory") myDir print(myDir)