Attributes and Expressions
From DataSplice
Most of configuration settings throughout DataSplice can utilize attributes and expressions to control how the applications behave. DataSplice uses attributes to define variables that can be used throughout the configuration to tailor how things behave, such as:
- Control various functions of DataSplice applications and plug-ins
- Access data from the current context
- Define commonly used values
Attributes are referenced using the following syntax: ${ATTRIBUTE_NAME}. This will replace the value of the attribute with the name ATTRIBUTE_NAME when the setting that references it is used.
Note that attribute names are case-sensitive!
Naming convention for attributes make it easier to distinguish attributes defined for different purposes. UPPER_CASE names help separate custom attributes from the values available through the current record that are typically Mixed Case. In addition, all attributes used by the various DataSplice products have a common DS_ prefix.
Contents |
Attribute Hierarchies
The feature that makes the attribute mechanism particularly powerful is that attributes can be defined at many different levels and can be overridden depending on precedence rules. Attributes can be specified at various levels
- System - The system provides several built-in attributes that are always available. For instance, DS_USER contains the current user name.
- Roles - Attributes from the roles the user is a member of can be used to define frequently used values within a particular application.
- Views - Each view can also contain customized control its behavior, perform lookups into other views, etc.
- Plug-ins - Client-side plug-ins can define events and expose values through attributes. For instance, the barcode value scanned by the user is available through the DS_SCANNER_INPUT attribute.
- Session - Attributes can be persisted to the user's session to track maintain values across multiple events.
- Current Record - The values of the selected record are also available as attributes using the field name. This allows the current values to be accessed using the same syntax as for other configuration settings.
The above attributes are combined in a hierarchical manner to generate the collection of values available when various events occur. For instance, when committing record changes to the server, you can access built-in attributes, values defined by the user's roles, and data from the selected record using the ${NAME} syntax.
Dynamic Attribute Values
Many settings in DataSplice are specified by expressions that are evaluated to determine whether or not certain behavior should be available. This allows many of the conditions and other settings for views to offer much more dynamic behavior. So rather than simply saying a record is or is not editable, the administrator can specify it is editable if a specific condition is true.
This behavior is also extremely useful for defining attributes. At times it is useful to define an attribute value when it is used, not when it is defined. Dynamic attributes get their values by evaluating an expression, which in turn can reference other attributes, access data in other views, and test complex conditions.
Dynamic attributes are processed by both the DataSplice Server and the Remote Clients, so they work online as well as offline.
These attributes can be used for a wide range of tasks:
- Look up values, such as default codes, associated with the current log in to reference in filters and defaults.
- Fill out basic information for newly inserted records, like locations and descriptions.
- Using existing restrictions from the master application as mandatory filter criteria.
The syntax for specifying a dynamic attribute is := <expression>, where <expression> uses the DataSplice expression syntax.
Attribute Validation
The DataSplice Administration Client will display errors when processing attributes and expressions. This is extremely helpful in diagnosing configuration errors, but it does require that settings are defined correctly or users will encounter these errors while using the system.
In addition, most of the settings that can reference expressions will attempt to validate the configured setting and display the value in bold red text if an error is detected.
In these cases, the extended text editor can be displayed which will contain the actual parsing or error message. This is very helpful to ensure you are composing correct expressions throughout the configuration.
Use the error message to determine the syntax error or other problem and correct it.
- In many cases errors will be displayed for views when not masquerading as a user with access to the appropriate role. This is because * the expressions reference attributes defined by those roles.
- In some cases errors can be ignored because the validator does not have access to all the values that will be present when the expression will actually be evaluated.
Basic Syntax
Expressions are written as generic logical statements, similar to SQL where clauses. Normal operator precedence rules are followed. Parentheses can be used to arbitrarily group items. The following operators are understood:
Arithmetic Operators
The following operators combine two arguments and return a result. Data types are handled automatically in most cases.
| Operator | Description |
|---|---|
| + | Addition |
| - | Subtraction |
| * | Multiplication |
| / | Division |
| ^ | Exponentiation/Power |
| % | Modulus |
| || | Text concatenation (Note that the addition operator will not combine text, rather it will attempt to convert the values to numbers and then add them together) |
Comparison Operators
These operators compare two values are return true or false in most cases.
| Operator | Description |
|---|---|
| = or == | Equality |
| != or <> | Inequality |
| like and not like | These process % and * as wildcard characters |
| ~= | Similar - see notes below |
| ~<> | Not similar - opposite of ~= |
| > | Greater-than |
| < | Less-than |
| >= | Greater-than or equal |
| <= | Less-than or equal |
| <=> | Comparison - returns -1 if the left argument is less than the right one, 1 if it is greater, and 0 if they are equal |
The similarity operators differ from the regular equality operators in a couple of ways:
- Text comparisons are case-insensitive
- If the right side of the expression is a comma delimited list it returns whether or not the left value is in the list (
${Value} ~= 'First,Second,Third') - The right side of the expression can be a pattern to apply regular expressions (
${Value} ~= /^http:.*/)
Logical Operators
| Operator | Description |
|---|---|
| is null and is not null | Returns whether or not the left argument has a value |
| ! | Boolean not operator (!IsModified("Field"))
|
| and and or | Combine multiple statements into larger expressions |
| in and not in | Returns whether or not a value is in a particular list (${Value} in ('First', 'Second', 'Third'))
|
Expression Functions
In addition to these operators, many built-in functions are available that allow expressions to specify complex conditions. Refer to the Expression Function section in the addendum for a list of available functions and documentation about the syntax.
