Scripting Basics: SDL Syntax
You can use any text editor to create Spectre scripts, but Workbench offers visual assistance to make these tasks easier. Workbench text editors include color-coded syntax highlighting based on grammar rules as well as auto-completion for syntax structure. Encoding for all SDL file types is UTF8.
TIP: If you make edits to Spectre files outside of Workbench, be sure to use the "UTF-8" encoding in the external text editor program.
NOTE: Many modules in Workbench also give you the choice of a GUI editor.
The following table lists some rules to keep in mind when editing the SDL.
SDL Syntax
Syntax Rules |
Snippet Examples |
Notes |
---|---|---|
Define only one tag per line. |
cplan "/cplans/autoexample.cplan" areas { title "Access Page" |
Three lines – 3 tags: cplan, areas, title. |
Tags can be repeated— they do not need to be unique. |
icon "/divetab-scripts/images/Data_Page_144.png" icon "/divetab-scripts/images/Data_Page_288.png" retina=true |
Two lines with the icon tag used for each. |
A tag can contain one or more text values enclosed within double quotes. |
dimension "Supplier Name" |
“Supplier Name” is the string value associated with the dimension tag. |
Strings are always in quotation marks. Use a backslash (\) escape character if you need to include the quotation mark in the string. |
my_strings "abc" "two words" "a quote:\"" |
Three strings associated with the tag my_strings. |
Backslashes need to be escaped when inside strings. When a string is inside an expression, backslashes must be escaped again. |
"\\" `"\\\\"` "\"" `"\\""` |
String with a backslash. The same string inside an expression. String with a quote. The same string inside an expression. NOTE: Escaping is not needed in multi-line strings or multi-line expressions. |
A tag can include numeric values. |
bar 10.5 12 |
The tag is bar, 10.5 is a fixed-point number, and 12 is an integer. |
A tag value can be an expression. Backticks are used for expressions. An expression is stored and evaluated later, possibly in different contexts, producing different values. |
filter `value("UnitsOnOrder") != 0` |
In these two examples, filter is the tag and the expression is defined between the backticks. |
A tag can contain an attribute, that is, a named value. An attribute consists of the attribute name and value in the form of name=value. |
reverse=true |
Three attributes: one with a Boolean value, one with a string value, and one with a numeric value. |
If a tag has multiple values, the values come before any attributes, that is, unnamed values come before named values. |
foo "x" 1 color="red" size=15.75 |
Here foo is the tag, “x” and 1 are unnamed values, and color and size are named values, which are attributes. |
Tag names and attribute names are identifiers and as such must begin with a letter or underscore. They can contain letters, numbers, underscores, hyphens, and periods. |
asdf _asdf asdf123 asdf-1-2-3 asdf.foo asdf_foo asdf.3_0 |
Names begin with a letter or underscore. Spaces are not allowed. |
Blank lines are allowed and can occur anywhere in a script. |
|
Use for readability. |
Newlines are significant in SDL and cannot be generally inserted in random places. |
build { text-input "/di_data_prod/EPIC/ARPB_TX_GL/2014*.dat" "/di_data_prod/EPIC/ARPB_TX_GL/2015*.dat" "/di_data_prod/EPIC/ARPB_TX_GL/2016*.dat" { column "GL_ACTIVITY_DATE" type="string" } } |
The text-input entry in this example has multiple files listed. It can be difficult to read, but should not be separated by line feeds in the script. The only line feed is just before the column tag. |
A comment is always on a line by itself. |
// this is a comment
# this is also a comment
-- and this is a comment as well |
Start the line with a double slash, a hash sign, or double dash. |
Multi-line comments use an open and close forward slash with an asterisk (/* comments */). |
/* a comment that runs on and on using more than one line should be concluded with a */ |
|
Multi-line strings can be included by starting with three quotation marks (""") on one line and ending on another line with another three quotation marks ("""). |
query """ SELECT Orders.OrderID Orders.OrderDate, Customers.CompanyName as CustomerName, Customers.ContactName as CustomerContact, Customers.Phone as CustomerPhone FROM Orders,
Customers |
SQL query strings are commonly multi-line. |
Multi-line expressions can be included by starting the expression with a triple backtick (```) on one line and ending on another line with another triple backtick (```). |
filter ```
user_property_contains("pfm-fac-id", value("Facility ID")) or
user_property_contains("pfm-gac-dep-id", value("Facility Code-Dept ID"))
``` |
For readability, enter the filter expression on multiple separate lines. |
Multi-line strings or expressions with backslashes do not need to be escaped a second time. |
"\\" ```"\\"``` "\"" ```"\""``` |
String with a backslash. Inside an multi-line expression. String with a quote. Inside an multi-line expression. |
Braces indicate parent and child blocks. When used, the start child brace ({) must be the last character on a line. The end child brace (}) must be on a line by itself. Indenting is recommended so that you can more easily see where tags and blocks start and end. |
elements { grid id="myElement1" {
row "Vehicles Sold Q1" row "Vehicles Sold Q2" row "Vehicles Sold Q3" row "Vehicles Sold Q4" }
} |
While editing code blocks, you can select code, right-click and select Format Selected to line up your blocks. |
Block illustration:
You can break up long expressions with triple backticks, and long strings with triple quotes, but there is not a mechanism for long tags. However, if an expression is involved, you can use the multi-line expression trick. For example, this long line:
can be coded into three lines as follows:
Note that an extra newline at the beginning or end of an expression does not effect the expression, so for instance you can put the final ``` on the next line.
See also: