Limitations and Best Practices for Defining Custom View Parameters at the Root Level in Ignition Perspective

Ignition
1

How many custom parameters can we make on root level of an perspective view?

2

I don’t think there is a limit. When you start getting to a large number of parameters, it could be useful to organize them in groups via objects.

1 Like
3

There's no limit enforced, but I wouldn't put more than a few dozen, mostly from a maintainability standpoint. Definitely group them into logical "namespaces" using objects. Also mark them all private.

4

I have to admit I have never really paid attention to the property restriction mode, and I realize that all the properties I have been using are public.

Now that I have read through some posts and the Ignition documentation on this, essentially is there any drawbacks to marking a property “private”, it being a view parameter or a custom property in a view ?

From my point of view and what I think I have understood, there is really no point in ever marking a property as public, unless you specifically want to use the Javascript injection through markdown trick ? Or am I wrong there ?

Thanks in advance!

5

Basically, yes. For any custom property at least. It really should have been the default in the property editor.

4 Likes
6

I’ve never paid any attention to the Access level of my props, so they’re all public. What is the benefit of making them private? Is it just a security issue, or is there a performance penalty in keeping them public?

7

You won’t be able to use them with any Actions other than script because they run in the browser. Am I correct on this one?

8

Public properties are automatically synchronized to the frontend over the persistent websocket connection we made - which means CPU load on the gateway and client will be raised, memory usage on the client to hold that data, and more traffic over the network. Meanwhile, literally nothing on the frontend can actually interact with those properties outside of module-added components or the aforementioned markdown-component JS injection hack.

I don't know the exact reason we didn't make all custom properties private automatically; perhaps optimism at the time about what offline mode would become and how it could make use of them, but at this point in time it's pretty indefensible.

While some actions do run "locally" - none of the ones that do have any way to interact with custom properties specifically.

2 Likes
9

Wow, good to know! I’m gonna start making all my props private then!

10

I just remember passing a private custom property to the Popup Action, and it resulted in undefined.

.

1 Like
11

If I make the root of an object private, do I need to bother making the properties within it private also? They don’t appear to inherit that attribute, and can still be explicitly set…

12

Honestly not sure. I would expect setting it at the root to be sufficient as well, but it's been a long time since I looked at the code.

13

Now that I’ve started making my custom properties private, I thought I’d mention a couple lessons learned for anyone who stumbles across this thread:

  1. If you make view PARAMS private, then changes in the value being passed will not been seen by the view. I made a table column view rowData private, and found that the value being rendered by it did not change when the table data changed.

  2. If you make a CUSTOM property private, you might have trouble passing it as a parameter to other views. When I tried passing one via an onClick Popup Action, it didn’t get passed. However, passing it via a script system.perspective.openPopup() did work.

4 Likes
14

This action is implemented on the front end, not in the gateway, so naturally would not have access to a private property. Scripted actions always run in the gateway.

4 Likes
15

Is there a way you can clarify this point?

I just became aware of this practice. For now, I’m going to make my custom properties private. However, I find it strange that if an object is private, a child of that object could still be public.

How can we test this case?
Thanks.