Mimic multiple Python package namespaces in single module

We would like to provide the implementation for multiple python package paths in the same ignition module. The sample code provides the example for registering a single path:

            new PropertiesFileDocProvider());

The implementation of addScriptModule registers all the public methods from the object ‘script module’, so we would obviously need to separate the implementation else all functions would show up for every namespace/path.

However the getRPCHandler does not allow differentiation by class:

public Object getRPCHandler(ClientReqSession session, String projectName) {
    return scriptModule;

Can this be accomplished?


Don’t use your script module instances as your RPC handler. Use something else that “multiplexes” the calls to the right place. Scripting and the RPC system are not related at all, except for that the examples use the RPC system to send client-scoped scripting calls to a gateway-scoped implementation.


If I understand correctly, we would also use the hook.getRPCHandler(…) when calling from a sibling module. The python package/path is no longer relevant, but segregating the methods to multiple objects is helpful for the programmer.

We have not found a way to multiplex the methods out to the script console properly just yet, but will keep working on it. Do you have an example for doing this?

Break up your scriptModule implementation into separate classes, by the namespace the content is to be exposed in. Call .addScriptModule() for each, separately. If necessary, multiple implementation classes can be loaded into the same namespace, to selectively expose functionality. (By project, perhaps.)

Be aware that a namespace that does not begin with system. will not be auto-imported into other scopes, and might not be reachable at all.


Here’s what worked:

  1. We started with the sample script module code.
  2. We created a separate interface and abstract base class for each python package/script file path that we wanted.
  3. We created separate implementation classes for each interface/abstract base class for each context. These classes were passed to the addScriptModule functions.
  4. On the gateway, we created an additional class that aggregated the gateway context’s implementation classes and implemented all of the interfaces, calling the appropriate implementation object as needed.