It seems like a project can only inherit things from one other project. In my scenario, it would be useful to have a project that is inherited by multiple children, and then those child projects might have to inherit from multiple parents. Is this on the roadmap for things that will be possible in the future?
Inheriting from multiple parents is not planned right now. It would be neat but much more confusing and difficult to implement and handle the edge cases.
1 Like
Alright, thanks!
I think one project can be inherited by multiple projects even now by setting their parent to one project?
Inheriting from multiple projects can be achieved by setting parents parent project and so on? Will it work?
I got that first part backwards, sorry.
I mean having a child project that has multiple PARENTS. As it stands, you can only select a single parent project, but maybe doing a “chain” of inheritance like that could work, but it would be messy and not super easy to maintain.
I agree, however not sure how often multiple inheritance will be required.
It will be nice if its built in to ignition to have some 3 or 4 parent definitions possible to avoid the messy sequential inheritance.
I am new to Ignition, so please forgive any beginner mistake I could be making here.
I am thinking of using the following idea, which I assume is a typical intended use case for inheritance :
- Parent project contains resources with parameters (UDTs, tags, windows/templates, etc.)
- Child projects inherit from parent, and bind values to those parameters to connect to real stuff (e.g. PLCs)
Limiting inheritance to a single parent feels kind of cramped in a scenario like this (although it is much better than no inheritance at all), as everything we ever intend to share like this would have to go into a single project.
Or is there another way that can be used in Ignition to achieve reuse of code in a similar way without multiple inheritance?
While Ignition only allows for single-inheritance, there is nothing stopping you from chaining inheritance into a sort of ancestry structure.
ProjectA:
includes resources which EVERY project should have access to.
ProjectB:
inherits from ProjectA.
is intended for use by projects for CustomerA, and so has its default database set to CustomerA's database.
contains resources like Views and scripts which are specific to only CustomerA.
ProjectC:
inherits from ProjectB.
is a front-end/runnable project which manages the warehouse operations for CustomerA.
Contains everything from ProjectA AND ProjectB.
ProjectD:
inherits from ProjectA.
is a front-end/runnable project for CustomerB.
contains everything in projectA, and nothing from ProjectB/C.
While it is fair to say that inheriting from ProjectX and ProjectY, where X and Y are not descendants of one another could be useful, it's also an absolute nightmare to implement/troubleshoot/utilize/maintain not only from a product development point of view, but an integration/design point-of-view as well. How would you clarify to a user where resources are coming from? How do you resolve resource name contention? What happens when script events call out to handlers which exist in both parent projects? ProjectX requires authentication, while projectY does not, so does the child project require authentication?
Chaos.
1 Like
Also, one additional point for clarity - tags and UDTs are (still) “globally” scoped - they don’t reside in any particular project, they’re part of the gateway itself. You can separate tags into different realtime tag providers, but you always have access to all tag providers in every project.
This is a good point, and works for “specializing” a code base in some sort of customer/site tree.
But if I would like to break up our code in “modules” in a “horizontal” way, each module acting as an independent library, I may want each “customer” or “site” project to inherit from separate modules, and this would require multiple inheritance.
Interesting scenarios, they help add clarity to the inheritance concept.
I’ll throw another scenario into the mix, this time including the MESGateway project that Sepasoft’s module uses in 2.0:
- MESGateway Project: owns the production model entries, model management screens (Add downtime, equipment,etc.), and scripts to interface with the production model. Project is set to Inheritable and it has no parent.
- Common Project: contains common scripts and templates that are reusable within any client project. Project is set to inheritable and has MESGateway as a parent (therefore, any scripts can use MES scripting to get model data)
- Client Project: Contains windows and local scripts; it is not set to inheritable and inherits the Common Project, therefore having access to common’s templates and script functions.
The only limitation that I see in this example is that if the Client project needed to have access to any of MESGateway project scripts, we would have to create scripts that implement those in the “Common” project, in order for the client project to use MES scripts.
Does this make sense? Thoughts?
Cheers!
Then you should just make that code into actual modules which you could then import into the Gateway, which each project could use as needed.
I had a requirement of distributing my gateway scripts to different projects requiring them. I first tried to define these scripts in a global project and tried to inherit this project in all interested projects. But the problem there was, the tag names for gateway tag change event scripts are not copied in the inherited projects and I had to override the inherited scripts to enter the tag names (different for each project as same names would trigger these scripts multiple times from each project inheriting the global project.).
I found importing the common project works better for my requirement, but I need to assign different tag names in tag change gateway event scripts. Its easier for me to save my gateway scripts in an empty project and distribute it for importing in other projects requiring them, for different versions of Ignition. I hope exporting and importing projects will continue to be supported in Ignition newer versions!
I am still unclear if inherited global scripts are equivalent to shared scripts in older versions of Ignition? My understanding of shared scripts in older versions is that only one copy will exist in gateway for all projects sharing them. Is that the case for all projects inheriting them (unless overridden ) or separate copy is created for each project inheriting them? (I am assuming the later is true).
Sorry for being a newbie here, but is it possible/practical to have vision/perspective elements “compiled” into a module, or do the module elements need to be defined programmatically or in a way that is different from what you would do in the designer?
Is there some sort of primer on modules showing the general workflow, and what it “feels” like developing a module compared to a standard project?
Modules are written in Java – Vision and Perspective are modules. As such, things in modules are defined very differently than you do in the Designer. Developing a module is basically writing an actual computer program – you can see examples of module code here.
We don’t really have a primer on module writing, because then we’d be teaching you an entire university computer science course. 
Thanks a lot for the information, basically what I was expecting.
A previous poster suggested writing the kind of approach I had in mind in the form of modules rather than project inheritance, which might have made sense (in our case) if modules could package project elements, but I understand everything is basically done programmatically.
It turns out I have a CS degree and significant Java experience, but at this time having as a strict requirement from anyone working on our project that they program in Java would be too much of a hurdle and kind of defeat the appeal of Ignition (for our use case). I would rather have to put all shared elements in a single project to be inherited from other projects, it seems it would bring the least complexity overall.
3 Likes