Hello all. I'm starting to cut my teeth in Ignition and had some questions about abstraction with regard to HMIs and wanted to figure out how the community at large is handling things. To start, by abstraction I mean sharing of resources so that different implementations of a thing can use the same "template" so to speak. To that end, I'm thinking about places where this could materialize in an Ignition project. To start, how are you setting up tag groups or just tag organization in general? Is there a best practice to doing this that allows you to scale your projects without much labor? Next, when you create an abstracted template to display the same kind of information for many different hardware systems, are you using UDTs passed as custom properties? Or something else? Finally, when you go to display these things in a perspective page, are you running any kind of scripting that just automatically adds new instances of your template when it detects them? I appreciate all of your insight!
The most useful design pattern in Ignition, IMNSHO, leverages Ignition tag paths to apply common UI elements to your actual architecture. That is, every re-usable View has a tagpath string parameter that serves as a complete prefix for the actual tag paths your UI elements use. Within those elements, there are basically no direct tag bindings, only indirect tag bindings that use the view parameter as a prefix.
With that approach, you can then organize your live data (tags) into repeating elements whose child names match your common views' expectations. Ignition's tag UDTs greatly help creating repeating live data structures, though it can also be done just with tag folders.
Many, many discussions:
https://forum.inductiveautomation.com/search?q=tagpath%20parameter%20order%3Alatest
(Welcome to the forum!)