Attributes

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.

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.

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.

Expressions

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.

Dynamic Attribute Values

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

DataSplice 3.1 will display errors when processing attributes and expressions, unlike prior versions that simply consumed the error and continued processing the current action. 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:

• + Numeric addition
• - Numeric subtraction
• * Numeric multiplication
• / Numeric division
• || String concatenation
• <=> Comparison - returns -1 if the left argument is less than the right one, 1 if it is greater, and 0 if they are equal (Spaceship operator!)
  
• ! Boolean not operator, i.e.: !isModified()
• is null
• is not null
• = or == Equality test
• != or <> Inequality test
• > Greater than
• < Less than
• >= Greater than or equal
• <= Less than or equal
• like This processes % characters as wildcards
• not like
• between Inclusive bounds test (ie: ${Value} between <min> and <max>)
• not between
• and
• or

Text operators are not case sensitive. Also note that separate operators are used for addition and string concatenation.

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.

Explanation of Built-in System Attributes

The following is a brief explanation of the built-in system attributes. The format used is as follows:

Other Available Built-in Attributes

Some attributes are built into DataSplice but are not visible as settings in the Administration Client. These attributes, however, can be referenced throughout the application to provide additional functionality. The following is a brief explanation of those attributes.