Tag Paths already have an underlying, structured java object. That is entirely orthogonal to the rename behavior you desire.
Why would it be orthogonal? If they have object references their printed path should just be a property, and then updating it in the tag browser should be able to update it everywhere it is referenced -- that doesn't seem to currently be the case though
Object references are constructed from configuration. Changing the references doesn't propagate to config.
Ah it would need a config propagation as well
Actually, even more than that. Altering objects and references, even if there wasn't configuration to worry about, still wouldn't suffice. Because for most of Ignition, the objects are not just one instance in one place, but instances in each of many separate processes, typically not even in the same physical hardware. So, in the real environment, alterations not only have to propagate back to the startup configuration, but also to all other instances.
It would definitely need to be an active function to push changes to everything, which is why I guess it doesn't exist.
It would be a supremely valuable functionality for development and maintenance, though.
I just wanted to say this has been an educational read. I suspect almost everyone getting started with Ignition will come across this debate at some point.
I feel like there should be a âbest practicesâ section of the documentation that explains the options of UDT vs tag paths, and when it is best to use them.
Specifically - my take away from this thread was:
- UDTs for structured data, but donât bind to templates/views
- tagPaths for passing to templates/views - with dropconfig tagPath support only available in perspective (currently)
2 Likes
Part of the reason for topics like this is that IA prominently features UDT binding in its training. Which produces a bias towards poor practices that a user has to unlearn to make headway in more advanced and efficient methods.
3 Likes
Best practices sometimes conflict with marketing material 