Hi Everyone,
Can anyone point me to the JSON schema for perspective’s view.json?
I am looking to dynamically generate views and would like to have some kind of enforcement to prevent broken views.
I see this post that gives the schema for SVG component but not the structure of view.json itself.
Thanks,
Noah B
What is your end goal here, what problem are you attempting to solve or bypass?
Ignition's strength lies in being able to re-use common views via indirect bindings and the like. If you are planning on making X number of pump(or other device) control screens, you are approaching this incorrectly.
Make a common control view, pass needed tagPaths or other information that can be used to build the correct tag paths and indirectly bind needed tags to view custom properties.
Hi Ryan, thanks for your response.
pass needed tagPaths or other information
This is exactly what I'm trying to dynamically generate. When a client gives say a csv of required process parameters to show along with other information, I don't want to have to manually configure each binding. Especially when I can feed a program or agent the requirements and the view.json and saves manual configuration.
To address the original question, the JSON schema would simply be a guardrail to make sure whatever is generating the view is valid.
You're talking about view.json of a Perspective View resource on disk?
If so, there is no schema defined for htis.
I still think this is wrong approach, but, I would rather build my standard view in Ignition and then program something to crawl the resulting view/json and adjust the target tag paths/members to what I was provided by the customer, and spit that out as a new view. Less likely to break the view compared to generating from scratch each time.
But at that rate, you are essentially just doing a glorified search and replace.
If you follow a consistent standard with how you organize your tags, you can probably get away with only having to change the tagPath that is passed to embedded views or popups.
Hi Kevin,
That is correct. For the perspective resource on disk.
So the only enforcement is at the perspective component level such as this example? How does perspective validate the view.json then?
view.json is a serialization format that is effectively private because it's an implementation detail.
It's serialized and deserialized with custom GSON serializers. There is no validation. Deserialization will blow up if you screw up the format.
Those schemas in the SDK examples are for a different purpose - they tell the Designer about what properties a component has.
1 Like