Trying to figure out the biggest changes for our module from Ignition 8.1 to 8.3

Module Development
, , ,
1

Hey Ignition team,

We currently have a module running in Ignition 8.1.19. The module is a simple form on a HTML page rendered by a Java class. We use the module to push some tags on a REST API.

In the back-end, there are a few classes that handle tag subscription, sending the data in batches, and then some persistent records, to save the data to Ignition’s database.

We would like our module to support Ignition 8.3, but it looks like there are a lot of changes and I have trouble figuring out to which extent. Even front-end wise, it seems as though we could now use React instead of plain HTML/CSS/embedded JS?

I’d appreciate if someone had more insights on the extent of the changes we would have to make on our module. No need to be precise, but maybe the few big milestones we might encounter while making the transition.

Thank you!

2

Is this HTML page being rendered from Perspective?

Much of the advice won't hinge on whether or not your module relies on Perspective, but it may help more experienced users give precise guidance.

Additionally, it may be good to clarify the method you have used to build this module.

If you are using Inductive Automation's gradle plugin and associated boilerplate, the specific details of that will help clear the unknowns.

3

Hi Paul,

No, the page is not rendered from Perspective.

We are using a GatewayHook extends AbstractGatewayModuleHook class to initialize and setup all the backend stuff and render the HTML page from the getConfigPanels() method. And yes, we are using the gradle plugin it seems like.

4

The two biggest changes to v8.3 for module developers are the complete removal of the Wicket config panel infrastructure, and the removal of all run-time use of the internal config database (PersistentRecord subclasses). The latter exists only for migration purposes.

It sounds like you will be starting from scratch.

5

First:

You have three primary options to serve webpages in 8.3. Only one is substantially different from 8.1:

  1. Mounting a servlet directly. This is the most powerful, and the furthest from our guardrails/guidelines. There are legitimate reasons to do this, and it gives you ultimate control over what the endpoint responds.
  2. Mounting "routes", via the route mounting hook. This is the way we generally recommend exposing arbitrary REST-like endpoints, including how the openAPI stuff is all mounted; the builders expanded a lot here in 8.3 but the basic capability is the same.
  3. Exposing configuration/status pages directly tied to your module's config. In 8.1 this was Wicket, in 8.3 this is all handled by the Gateway automagically and does require you to provide React compatible pages. This is also the least documented and hardest to get started with mechanism, because there's a lot of bleedover between the different worlds.

The PersistentRecord class is entirely gone and the entire configuration management system is different in 8.3 compared to 8.1. It's, in my opinion, a lot better and there's a lot of advantages, but it's going to require some overhaul of any 8.1 module.

2 Likes