I can't shake the feeling that I am underutilizing Ignition's project inheritance feature and may be ignorant of the benefit I could reap by using it more effectively.
Project Inheritance allows one project to inherit resources from another project. If you have project resources that you want other projects to use such as views, windows, scripts, templates, or pipelines, you can create an inheritable project allowing other projects to inherit those resources.
I haven't really run into a need to serve more than one project from an Ignition gateway. Are there strategic reasons to use project inheritance outside of scenarios where multiple projects are being served from one gateway?
I've had a client suggest use of project inheritance as a way to manage a set of "standard" views/styles across multiple similar sites by having those in a parent project that I sync across gateways at each site... but since projects don't contain the tags and UDT definitions that often correlate to those views I'll still need to manually sync changes for those across gateways for each site and haven't seen reason why I wouldn't do the same for views/styles and whatever else might be in a inheritable project.
Just musing but I suppose project inheritance might be useful to limit modification access to differing developer groups. Each project in a multi-level project inheritance scheme having different role based permissions. Again, I have not had compelling reason to add that complexity to an environment.
In any case I'm interested in any real-world justification/scenarios the community might offer of how project inheritance has been used strategically to meet project/operation objectives outside of scenarios where multiple projects are being served from one gateway... and if that is even a valid consideration.
Another option is to create several inheritable projects. You can have one inheritable project dedicated for each type of resource: one for scripts, one for views, one for templates, one for pipelines, etc.
What is the perceived benefit of doing that? Why would one want to split each resource type to separate inheritable project?
That seems pretty contrived to me, to be honest (the example of "one project per resource type", specifically).
The main place I'd absolutely recommend project inheritance is a global script library; pull your utilities up as far as possible and then possibly have a 'leaf' global scripting project, as well as use that scripting project as a base for all of your other projects.
However, it's very possible that you just haven't come across scenarios where inheritance offers you any benefits. For a "simple", or at least limited scope system, there's absolutely nothing wrong with a single project system.
Your reusable views should take tagpath string parameters, and never use UDT properties at all. Ever. (UDT UI properties have been a misfeature since they were created in Vision many years ago. IMNSHO.)
@Pturmel Agreed, I pass at tag/UDT instance references to reusable views by path (string). My statement still stands as the reusable views are built to expect a specific UDT instance type (with expected member tags) at the path passed as a parameter.
Is the rest of your comment related to use of custom properties on the top level of a UDT definition (as differentiated from UDT member tags)? What is your rationale for your strong stance against them? Can't say as I have a habit of using them, mostly because they don't appear in the tag browser making it easy to forget they exist. I imagined they might have an effective use though.
@PGriffith, Why? On a gateway you designate a Gateway Scripting Project so why would there be a need to split the scripts out to a separate project (aside from the idea that only one project can be the 'Gateway Scripting Project'). I'm in Perspective headspace where darn near everything is gateway context. I'd think that justification only really applies when there are other reasons to have multiple projects on the gateway.
...pull your utilities up as far as possible and then possibly have a 'leaf' global scripting project
Not following... what do you mean by "utilities" in the statement above, is that meant to be the same or different than the collection of scripts comprising the "global script library".
[Update] I think I understand better after a reread. You're suggesting maintaining your "global script library" at the highest level of project inheritance, lets call that the GSL project (inheritable). Then having one leaf (child project) of the GSL project that just exists as the gateway script library (no UI) and have separate leafs from that GSL project for your Perspective/Vision UI projects. Is that right? If so what is the perceived benefit of that organization?
You may be executing in a Project Scope, or not, but everything in Perspective executes on the Gateway. Also, you don't have to designate a Gateway Scripting Project (you probably should, but there is nothing that makes you do it unless you need to call some functions outside of Project Scope).
If you have a Gateway Scripting Project, and you maintain a script library there, then making your design project inherit from it means that any scripts in the Library are available in and out of Project Scope.
Of course, as far as I know, there is no reason that the project you design in couldn't also be the gateway scripting project, there by eliminating the need for inheriting from another project.
Just adding on this, another possible use for inheriting projects on a single project system is if you've developed some kind of company-wide template for projects.
I've had it before where we were expecting several small projects, so I developed a template project that could be imported and would bring across normal embedded views, styles and scripts that we didn't want the engineer to modify but could then use.
This was prefered to just importing the items individually as we had some ability to version control the inheritable project as a single point rather than a dozen or more zip files floating around our servers.
If you have expected member tag names, then you can get any desired element with indirection using a concatenated suffix, without needing any UDT property. This gives you the flexibility to pass any folder path that happens to have the correctly-named elements. Whether the original UDT, any child type UDT, a non-related UDT that happens to have those elements, or a simple folder structured to match the original UDT. Or some of the above in a different tag provider that either doesn't have the exact same UDTs, or doesn't have UDTs at all.
First and foremost, is that UDTs themselves are non-project, globally-scoped resources under the tag provider hierarchies. UDT properties are always defined in project-scoped user interface resources. This is a fundamental boundary violation that leads to constraints on otherwise transportable/interchangeable resources.
Second, is that UDT properties have a long history of performance problems that are alleviated by using tag paths and indirect bindings, bindings targeting what would have been UDT members.
UDTs are wonderful. UDTs as UI properties' datatypes are an abomination.
Now if only there was a way to link templates in Vision to UDTs so that drag/drop still worked (just like Perspective) but would pass in the tag path instead of requiring a UDT parameter. (If there is a way, I'd love to know it because right now I'm dropping templates on the screen and copy/pasting tag paths).
I’ve worked on a project where we had 5 similar sites that we were designing from scratch in Vision. The templates got extremely involved and we were still making small tweaks throughout the commissioning stage. Fortunately, we divided up the templates, scripts, and some common windows into a global project, so we were able to take this global project and entirely replace it on the other sites (in development) without affecting any of the site-specific content. We did need to update UDTs separately, but the global project covered a lot of ground.
Awesome that this is now "Planned"...when I upvoted it before you made this comment, I think I was the 3rd upvote, and it didn't have a tag/status. Thanks for adding this to the list!
