You need to update the beaninfo path still:
It needs to be the fully qualified package name where your beaninfo class(es) are located (org.example.designer.beaninfos). The actual beaninfo classes are looked up at runtime, reflectively.
1 Like
That was it - I guess I didn’t actually save that change and thought I did.
That’s good for now. Will work on the underlying date calculation logic for a while before coming back here in a few days for the next step - exposing the properties I want to from my component - the selectedLabel from the dropdown, and the date property from the PMIDateTimePopupSelector from both components, but exposed as “startDate” and “endDate”.
This did fix the NPE error from before as well. Still have the actionPerformed string printing twice when a dropdown is changed for some reason but doesn’t seem to be detrimental currently.
You really should update your package names to match your true module ID. The more you do, the harder it will be.
1 Like
There seems to be a lot of changes in the structure of classes and packages from version 7.9 to 8.1.*. For example package com.inductiveautomation.ignition.gateway.sqltags in 7.9 SQLTagsManager (ignition 7.9.3 API) (inductiveautomation.com) is missing in 8.1. Similarly the sdk examples given in older sdks (such as AbstractSimpleTagsProvider something like that) based on which we developed our modules are not present in the sdk examples architypes The old modules don't compile on new version of architypes. So, we will have to maintain separate version of our modules where ever its not compiling! Even if the example projects were maintained same across each version of architypes we would be knowing how to port our modules across all versions of architypes.
Its safer to use scripting functions to develop our module functionality rather than use a compiled and built .modl approach though compiled ,modl approach will be more efficient and desirable. We need better documentation for class files of Ignition than just javadoc !
Ignition follows semantic versioning. 7.9 -> 8.1 is a major version change (technically, a major and a minor version change). Both are 'allowed' by semantic versioning to make breaking changes, and you'll find that we actually strive to only make breaking changes during those version bumps. It is impossible to guarantee that a compiled module will work on multiple major versions, but as Phil can attest, it's very possible to make a module that supports a broad swathe of every patch version within a major/minor pair; e.g. you can compile against 8.1.0 and be able to run on every 8.1.X version. With reflection, you could even have 'progressive enhancement' as new features become available in new Ignition versions, though I would generally advise against it.
I don't know why you would ever expect a 7.9 module to "just work" in 8.1. Similarly, you can absolutely expect your module to have to be restructured to some degree and absolutely recompiled to run on 8.3.
I am not expecting my older version of modules to work on newer ones (especially with major or minor version changes), but even to port to new versions of sdk I should know where the packages have moved to or gone, and what alternative packages I must use instead! (for example the SQLTagsManager (ignition 7.9.3 API) (inductiveautomation.com) is missing in 8.1) We have to rebuild our modules for new major or minor versions when they break, we have to know how the old examples are to be rewritten with the new libraries. Though modules are more efficient than scripts , but scripts are easier to port across major/minor version changes and are well documented. Same examples for all sdks would have helped us in understanding the changes better perhaps.
Well, that's always been the deal. You can write a module, and get the benefits of static typing, deeper access to internals, obfuscation of your internal logic, and more control. Or you can write a script and be more within the 'guardrails' of what we provide. We don't really offer much documentation for the SDK outside of the Javadocs at present, though we're hoping to change that soon. A lot of it is that we just don't/didn't have the resources to do a good job of documenting things while we were also busy rewriting the code, and the SDK is not as immediately important to most customers as the software itself.
I expect the 8.1 -> 8.3 transition to be much better documented both for end users and for module developers than 7.9 -> 8.0.
3 Likes
It is understandable that your priority is delivery of the end product rather than sdk and its documentation! Although the scripting documentation is updated and well maintained as its part of the end product that you are delivering.
However, I was just thinking if these scripting functions are made accessible as java functions (they are internally java functions) through compiled modl files somehow, then it would be great! It would bring best of both the worlds to the end user as well as module developers. If the scripting functions can be accessed thru java programs in our modules then they won't break with version change as we would be using the well documented scripting functions and even if they break its well documented and we can easily do the changes in our modules that use them.
This will allow us to develop and test our modules using scripts and then compile them into .modl files for efficiency and security of our code. we don't need to understand Ignition architecture and complete javadocs and be an Ignition developer to be able to develop modules for Ignition. I hope I am making sense?
This is an exciting update! I hope the developer panel in the Fall expands on this improved documentation effort.
1 Like
Sorry, @PRAMANJ, but module development has always been a moving target, and IA has always stated that its use is not officially supported. You have to learn on your own, and the level of complexity is such that I doubt a tutor would be much help. The examples, limited as they may be, are still the best starting point.
The most important thing is to start porting to new versions well before you need them. Almost all of my modules have been broken at some point by API changes, but since I've tried to keep up, each case of breakage was somewhat constrained.
1 Like
You can, though the calling signature is going to change; some scripting functions accept plain Java arguments, but most, in order to accept keyword arguments from Jython, accept a PyObject[]/String[] argument pair that's extremely awkward to call from Java. It's usually more ergonomic, from code, to rely on the underlying API methods; but that then exposes you to the API surface changing across major versions. No easy answer.
I understand, IA should not be constrained by anything in developing new versions of Ignition. However, ability to write your own modules and integrate them in Ignition was a key differentiator and one of its USP's for Ignition as a product from other SCADAs. Exposing all API's with some examples for gateway, designer and client module was very attractive proposition to many developers they thought they could integrate their unique ideas seamlessly in Ignition easily! However its not easy to understand the API's and use them correctly, that too when they are ever evolving. Of course if your modules use a few handful APIs which you can upgrade with each new version.
I think it would still be worth the effort to develop such "hybrid" approach to module development, as it would bring us best of both the worlds - well defined and documented and UpToDate scripting libraries and JAVA native libraries such as JAVA's Socket libraries instead of JYTHON's or using any JAVA third-party libraries etc. Ability to wrap the scripting functions in a JAVA module and compile and sign and deploy as .modl file would also protect our IP which is missing in scripts.
It would be great if IA can include an example project in the example architypes to show how to call scripting libraries from JAVA however awkward they may be. Or simply add in scripting documentation few examples of how to call different types of scripting functions from JAVA.
API: Awkwardly Programmed Interface
Isn't that the nature of APIs though? They get built under the guises of convenience and security, and then, they continuously break the things that are dependent upon them with each subsequent refactor or "Improvement." More than once at the beginning of a project while discussing the creation of an API, I have asked the question: "Is this API even needed?" ...while simultaneously imagining all of the inevitable problems and ways to get around them. It's not a barrier to entry; it's just part of the job.
1 Like
Still is. Ignition has a wide and varied collection of third party modules. And not just in the module showcase. That wide variety, and the large numbers of involved developers, refutes your implication that this is "too hard".
Whose effort? IA has their hands full developing formally-supported features. Efforts to support the SDK will take labor away from that. Considering the large job this would be, I don't see the same justification as you. If anything, I'd like to see IA flesh out the javadoc before any other SDK support efforts.
Don't forget that several people and organizations are developing useful modules in public. You could participate in those efforts as a learning exercise.
It's going to be a lifetime effort to master all APIs and it depends upon one's interest, motivation and need to learn them. It's not too hard if they are going to need and use them on regular basis.
Of course, effort on the part of developers to use the awkward calling of these functions from java. However, a bit of effort on the part of IA to give the concept behind it and a few examples of how to do it just to get developers started faster. It won't be much of an effort for IA as they are architects of these functions rather than we trying to figure it out ourselves by trial and error and groping in the dark.
The SDK hasn't existed but for a small fraction of a lifetime, and many people mastered large swaths of the API in a couple years of part-time effort. You can do it, too.
I don't find very much in the API that is awkward. It conforms very well to the java way of doing things. Your complaint essentially boils down to "I don't want to spend any time to learn, please hand this to me on a platter."
Even if IA hands out platters, no one will really be satisfied, because they won't have learned how to do anything without platter after platter.
Don't hold your breath waiting for IA to do this for you.
I just echoed what @PGriffith said about using the Jython functions from JAVA , not about javadocs, please see it in that context.
No that's not what I am saying! (You seem to have a lot of preconceived opinion about me!) I am just saying give few examples of what PGriffith said about the awkwardness the oddities and pitfalls involved in calling these Jython functions from java so that we can get started quickly and correctly instead of learning the hard way. Of course, we can learn it on our own by experimenting and this forum is there to for help as we can post specific problems when we do trial and error.
The maven central repository has 5 versions of Ignition repositories. Which versions of Ignition do they correspond to? Does building and testing our modules on all these repositories ensure its compatibility with all supported versions of Ignition?
Just to clarify, it's not my thread, I am not the one asking for a tutor, (in case you overlooked it). I just continued on this thread which was started by @ bkarabinchak.psi in Jan 2022.