This came up as a possible solution for an obstacle I encountered with SVG layouts. It was not viable for other reasons, but I wanted to ask the question for future reference. The SVG layout represents a few dozen functional objects, and I looked at using message handlers to traverse the elements by name instead of configuring tag bindings.
How reliable are Perspective messages? If the only function configured to change the color of an SVG element was a tag change script that sends a message, could state changes be missed? Do tag bindings have some ability to recognize desync of source and destination values? Could some similar capability be implemented with messages?
They're reliable, but also potentially not suited for this use-case. As they're not a binding, they only execute the associated code when the handler receives a "broadcast". As such, the following scenario would likely result in your svg not having the appearance you'd expect.
Scenario:
- The svg is saved as color yellow, with the expectation that a tag broadcasts a change to red when entering a high state, and green when entering a low (non-high) state.
- Users start a new session.
- The svg would load as yellow because that's how it was saved, and would not change appearance until the tag changes value. For tags which don't change value very often -- or which don't change state from high-to-low or low-to-high very often -- this results in no message being sent or received, so the svg would not change state.
Drawbacks of using Message Handling:
- Might not broadcast during every value change, depending on logic supplied by you.
- There's a logical separation from the sender and the receiver in that you have no insight into the keys provided within the payload.
- Scope can be confusing, and is difficult to scale out later if you need a broader scope.
Benefits of using Message handling:
- You can create multiple sources of the same message, and still have it digested in one location - or multiple locations if needed. This allows for setting up one listener which can act upon information from many different broadcasters.
- Scope allows for limiting who can hear the broadcast message.
Why would you not use a direct binding against the Tag in this scenario?
1 Like
Why would you not use a direct binding against the Tag in this scenario?
I asked this question for educational purposes. I am new to Perspective, and I want to expand my capacity to think laterally about problems. Thank you for your informative answer!
The original motive was simple laziness - the SVG layout elements are deeply nested due to organization in layers, and every time you add a binding the JSON collapses in the designer. Writing a few lines in a message handler that control an arbitrary number of elements was enticing. As you said, there is also an advantage to having multiple sources trigger the same script, and in having one script that can control a dynamic set of objects. The SCADA I am developing will become a template for this OEM's projects - the projects are all very similar, just with different equipment names and layouts.
I think it would be possible to use a startup script to poll the current state of all the tags and set the initial state. If the messages are reliable, then at least I know there's an option to do something like this in the future.
Okay. As far as reliability is concerned there should only be two things you need to consider:
- Perspective listeners will only hear a broadcast message if they exist in the DOM. This means that if they're in a Popup but the Popup isn't open, then they can't hear the message. Once the Popup is opened and the listener is in the DOM, then it will start hearing broadcasts. This can also potentially occur for listneres in Docked Views (if there is more than one Docked View on that side) and Carousels (if the instanced View is not the current slide).
- Race conditions when using multiple sources. Consider you have multiple broadcast sources all sending the same message with different payloads. There's no telling when a message will be sent/received, so your listener is going to handle each as payload as it is received; this can lead to situations where one source is sending "green" while another one is sending "red", and your listener is going to use each in turn - finally settling on whatever was received last.
1 Like