Ignition 8 doc mention
Inheritable Project Examples
There are many ways how you might want to configure and organize your inheritable projects. It’s whatever works best for your organization and design projects. Here are a couple of common ways to organize your shareable resources.
- You can create one inheritable project that contains many project different resources: scripts, pipelines, views, templates, windows, SFCs, etc. This is one inheritable project containing all your inheritable project resources.
- Another option is to create several inheritable projects. You can have one inheritable project dedicated for each type of rersource: one for scripts, one for views, one for templates, one for pipelines, etc.
For the second use case, I don’t understand ?
A project can only have one parent.
So if there are one inheritable project for script, one for views, …
How to use them for the same project ?
Perhaps it means you have to cascade inheritable project ??? and the project has the last one as parent ?
Is there a way to build project composed with multiple inheritable projects ?
We try the build projects with optionnal standard parts.
Yes I guess that’s the only way we can simulate multiple inheritance in ignition projects right now.
No. Chain inheritance only. Welcome to the whining club. /:
I think its even possible to IMPORT one project into the other, there by copying multiple resources in another project in one shot, that’s what we used to do before the inheritance was supported by Ignition ! The only difference is that importing will copy even the common resources such as client tags etc.and you have to overwrite or ignore the existing resources So while saving the parent projects for importing into another project, save only the resources that you want to export (or be inherited in to another project) . So you can import multiple projects in to a project there by creating the effect of multiple inheritance. I guess the project inheritance has another difference that the inherited resources cannot be edited there by giving the effect of private resources , which can of-course be overridden by you explicitly.
I don’t know under the hood how inheritance differs from importing except for the privacy aspect! I have been able to manage importing my gateway scripts by saving them in an empty project and importing the project in a destination project. Another advantage of importing projects over inheriting is that I can import a project in an existing project where as I can apply inheritance only while creating a new project! Correct me if I am wrong! Whats the best and recommended practice?
A key feature of inheritance is that bug fixes and other improvements to the parents automatically show up in the child projects. As far as I’m concerned, that’s the key point. Copying resources around and tweaking the results is time-consuming and error prone.
Which is why I’ve been whining about multiple inheritance. The “library” model of inheritance is simply superior to single inheritance.
Oh I didn’t think of that! A single source of truth is the key advantage here. I have been re-importing projects with an overwrite option to reflect changes in resources!