I was wondering if using a standard MVC approach would benefit the design of a software project using Ignition?
The general idea would be to design all the windows needed but not configuring them nor the items used inside each window. Instead, a script (or many scripts, depending on the structure of the project) would be created, centralising the behaviour of all the components. This way, one person can create the windows and focuses on the “view” when another one focuses on the “controller” by creating scripts which will describe the behaviour of the items.
A benefit would be that we don’t need to find the item to change its behaviour (when we have a lot of windows), but just open the script file and change the code inside.
Would it be a good way to design software in Ignition? Is it even possible to do so? What about performances comparing to standard approach (see user manual)?
It is possible to design and implement Ignition projects in the way you have described. I have seen it and done it in Ignition and I love it.
The problem with the traditional style of scripting in Ignition is that in complex windows and projects we end up with very many small scripts all over the place. It is much nicer to have the event scripts centralized and organized in project Python modules.
We implemented a small software framework on top of Ignition that centralizes event scripts into single project Python modules. For awhile I have wanted to extract this framework and give it to others, because it is a nice way to implement projects that require lots of Python scripting.
Performance is good – the main bottleneck in projects that I have seen is database queries and other to and fro request/response between the Gateway and clients. This bottleneck is unrelated to the time it takes to execute Python code.
There’s no way to attach scripts to component events other than in the designer, so I’m not confident you could actually separate out much of the scripting. If you try it, let the rest of us know how it turns out. (-:
So, if I understood well, it is not possible to do it with the basic Ignition, only if we put an effort to build a layer on top of Ignition. But the general idea could be worth the effort.
In this case, I will try to spend some time to think about it
I like the concept and would be very interested to see how Nick achieves it.
From Inductive Automations point of view, would it be very difficult to implement an optional additional interface to all the scripts on a screen that presents them in some kind of XML formatted document? That way, at the option of the design engineer, all the scripts for a particular screen could be edited in one place. The XML keys would identify which part of each component each segment of scripting applied to. Not sure if my vision here is clear.
