Best Practice: Perspective Change Script vs Property Binding Transform

[mike.hoeneise]

For example when we want to load data i would personally add a property binding to the data property and do a script transform to get the data based on the input value of the binding. Now i could do the same using a Change Script on the value which should trigger getting the data. Is there a reason why i should use a change script? is it faster? is it better for performance?

The only case which comes to mind on my side is when i would have multiple bindings to the same property then the binding transform would trigger for every connected property but when i use a change script it would only trigger once and do all the stuff at once.

[David_Stone]

Where are you performing these bindings and change scripts?
Are you talking about change scripts on props in perspective views or on tags in the tag browser?

[mike.hoeneise]

I am Talking about properties in views

[deon.korb]

The rule of thumb is to use transforms to manipulate the value from the binding.

E.g. your binding gets an integer, a transform maps that to a colour.

When using a script transform, it gives you the opportunity to do anything including bad things.

Good practice is not to perform other actions in a script transform, use it only to transform the raw value.

[David_Stone]

I think there are two very different use cases for the two methods.

A transform modifies the data from a binding then inserts it into the bound property.
A transform does not listen to a property and run a script.

A change script watches a property and runs a script when it sees a change.
A change script does not modify the data in a property or bind to a tag.

A property does not change unless you have either applied a binding to the property, passed a parameter to it or written to it via a script. Therefore you would use a property change script to handle the event that is a change in the property. You should not use a binding transform for this task as a binding transform should only change it's own return value for readability and maintainability.

When you set up bindings, you should set them up to output the best form of the data that you can use. There is no point making intermediate properties then applying change scripts to them that copy returned data into other properties. There is also no point making intermediate properties and adding additional bindings to transform that data.

In short, bindings are for data flow and transformation, change scripts are for calling methods on an event occurring to that data. Change scripts don't have a return value, transforms do, one or other will always be the better option based on the task you are performing.

As far as use cases - Change scripts work well on view parameters to detect the changes passed from the parent view, no way to add a transform here as the binding is in the parent if at all. Change scripts work where you may have multiple scripts that write to a prop and you need to monitor and log that event, again there is no binding here, so nowhere to put the transform. Also places where you are calling a library script like a database insert are best done from a change script, as there is normally no return value to get or use in the calling view.

[mike.hoeneise]

So for example i have a view input param like a ID and i want to load data based on that ID i should use a transform because it modifies the input and returns something. But when i have something which does not return anything like a db update/insert or something else i should use a change script. Is there any performance difference between those two?

[lrose]

@mike.hoeneise

So for example i have a view input param like a ID and i want to load data based on that ID i should use a transform because it modifies the input and returns something.

This is still a bit too broad.

You use a transform to transform the value before it is used elsewhere.

You use a change script to react to a value changing.

Any time that you're using a script you have to pay the performance price for firing up the interpreter. That doesn't mean don't use them, it's just a fact of life. However, for transforms, if you can accomplish the task via another method (say an expression) then you should take that route.

Here are a couple of posts on the matter:

Ignition Best Practices

This is an interesting question, because it's true that most of IU is geared toward beginner level/just getting started content, and we don't really have much that targets the intermediate-to-advanced skill level. I'll start with some general wisdom: If you don't have to script it, don't. If you do have to script it, prefer to write it in a project script rather than a 'magic pushbutton'. Don't repeat yourself, but also write everything twice, because bad abstractions can hurt more, and chanc…

Building for Performance

In this example, #3 is the most performant, though it could be argued that the performance gain in this instance would be negligible. Anytime you add an additional processing step you add latency. In general for the best performance I follow these guidelines: If you can achieve what you want with a binding, use a binding. Always use the binding type that is the most direct. (e.g. if all you need is a binding to a property use a property binding, not an expression binding.) Given the choice b…

Tag binding or expression to read dynamic list of tags

Collected some overhead stats. Added a sixth binding for comparison, and made them all trigger from a common reference. The new expression transform looks like this: nanoTime() - {value} It is notably faster than the other transforms. To make the recorder() run smoothly, I made a trigger timestamp with now({this.custom.pace}) and set pace to 200. Then I modified the transforms' first stages to look like this: asList( {this.custom.trigger}, nanoTime() )[1] The non-transform tests of run…

[mike.hoeneise]

Alright. Considering the fact that each script which is used fires the interpreter i could reduce the cost of performance (just theoretically) in this case:

property.A
property.B
property.C

property.Input

here property A B and C have a binding to the property.Input and have a transform. This would fire the interpreter three times. When i had used a change script on the property.Input instead and set the values of property A B and C from there i would have only fired the interpreter once right?

[pascal.fragnoud]

Premature optimization.
Bindings are easier to follow and maintain. Assigning values from a change script can quickly become complicated. You can't predict where exactly the values come from. Nothing is stopping you from writing to them from multiple scripts, and it's easy to make a mess.

If you want to compute multiple values out of one source in one single script, you could have a custom property dictionary hold all of them.

If you want "better" advice, show us an example of processing you're applying to your data.

[mike.hoeneise]

Alright that was all what i wanted to know.

Thanks a lot for all your Answers.