Scripting in Perspective

This section is designed to familiarize you with some of the basics of Python scripting in Perspective. Perspective scripting is particularly powerful, and can be used to control and fine-tune many aspects of project design.

For a more general view of scripting in Ignition, and an introduction to Python, see Scripting in our Ignition Platform section.

Perspective Scripting Fundamentals

Though Perspective uses the same basic platform (Jython) as other scripting environments in Ignition, interfacing with some unique features in Perspective might make it feel like a new scripting experience. Here are some key details that might be important to Perspective script writers.

Scopes

Perspective does not have a "Client" scope, because unlike Vision, Perspective does not have clients. All Perspective scripting is run on the Gateway, although session-specific functions (like navigation) will only affect a single session. Critically, this means that:

• Client-scoped scripting functions (system.file, system.gui, and system.nav functions) will not work in Perspective.
• Other scripting functions, like system.util.getLogger(), will run in a Gateway context.

Perspective Data Types

Component properties in Perspective are structured as JSON. However, interacting with them does not require any kind of specialized knowledge. Critically, every property in Perspective is one of three types:

Type	Description	Example
Value	A value is a simple piece of data, usually a number or string. Assigning a value to a value property is just like assigning a value to an ordinary Python variable.	self.props.text = "My Text" self.props.startAngle = 5
Object	An object is structured like a Python Dictionary, holding any number of elements. Each element can be a value, object, or an array.	motorObject = {"motorNum":1,"motorState":"Running"} self.custom.myObject = {"operationNum":15,"motorObject":motorObject}
Array	An array is structured like a Python List. Unlike an object where each element in the data type has an associated key, elements in an array only have a position, or offset. Elements in an array can be values, objects, or other arrays.	rowObject1 = {"city":"Folsom","country":"United States","population":77271} rowObject2 = {"city":"Helsinki","country":"Finland","population":625591} self.props.data = [rowObject1,rowObject2]

Object Traversal

In scripting, we can use component properties and methods to access related components, and view and session info. See Perspective Component Methods for details.

Scripting Transforms

Any property binding can make use of a Script Transform to apply any python script to the output value of the binding. For more information, see Transforms and Script Transforms.

Extension Functions

Extension Functions can be found in the Script Configuration window in certain Perspective Components. They allow users to add extended functionality to the component via scripting. These functions are generally more advanced and require better understanding of Python. Extension Functions differ from Event Handlers in that they are not event driven and are called by their component for a specific purpose when appropriate. Extension Functions are often called when the component first loads on a view or when it receives new input. For example, the Perspective Alarm Status Table has an Extension Function named filterAlarm. This function is called by the Alarm Status Table for each event before it is displayed in the table and it allows users to control what alarm events are displayed on the table or not.

From an object-oriented point of view, Extension Functions create a custom "subclass" of the base component type. Your subclass can then override and implement parts of the functionality of the component itself, in Python. Following Python object-oriented methodology, each extension function's first argument is called self. That is because these are methods that belong to the component's class itself, instance methods. The value of self will always be the component itself. Notice that this is different than Event Handler scripts where you are also given an event object in your scope. When you write an Extension Function, there is no event object so the component is given to you as the self object instead.

Each component Extension Function comes with its own documentation built-into the function's default implementation using a standard Python "docstring". The built-in documentation will contain descriptions for the arguments the Extension Function takes in as well as its return value, if any. You will find that you are unable to edit the function's signature or docstring. Changing the method's signature (arguments or function name) would prevent the component from calling it correctly. Changing the docstring could be misleading or confusing as you would lose the documentation for how your implementation of the function should work.