Accessing Gateway Context from Common Scope

Module Development
1

So I am trying to instantiate a SimpleTagProvider in the common scope. For this, I need access to the GatewayContext.
However, my common scope class is not created through my GatewayHook, but rather at runtime via Python hooks.

I have tried creating a static method something like this on my GatewayHook:

public static GatewayContext getGatewayContext(){ return instance; //where instance is a static reference to a singleton of the hook, more or less. }

But common scoped classes can’t seem to find the Gateway scoped classes. If I try to fix that, I get circularity warnings.

Not sure if this is a build.xml/module.xml issue or if I’ve hit a genuine feature wall.

1 Like
2

Hello,

What exactly are you a referrring by the “common scope”? AFAIK, the gateway context is only available on the gateway, so what you are trying to do does not seems to make sense. A simple tag provider is running on the gateway, so it needs to be defined in the gateway. Maybe you should give a little bit more details on what your are trying to do?

Cheers

Nicolas

3

The scopes are Client, Designer and Gateway.

There can be directories or projects called Common which will be used in all scopes.

Your SimpleTagProvider will need to be created in the Gateway scope. The scopes have things that are not accessible in other scopes. For example the GatewayContext object is not accessible in the Designer and Client scopes. Various functions and objects and classes in the Client and Designer scopes are not accessible in the Gateway scope.

4

The gateway context is only available in the gateway. Most contexts extend from BaseContext, which contains the getTagManager method. What are you trying to do exactly?

5

I am trying to provide methods in python to Gateway and Client scripts where:

  1. The script-writer defines what data they want the module to get in a relatively high-level way.
  2. The module writes to a tag on a predetermined, but not necessarily pre-made path (e.g. /machine/datapoint)

I would prefer for the tag creation to be automated, hence the desire for a simple tag provider.

6

These were all pretty helpful, actually.

What I’ve figured out is where ever I want to add script module (Gateway/Designer/Client), I need to pass in context and/or context dependent objects with an new instance such as:

	@Override
	public void initializeScriptManager(ScriptManager manager) {
		super.initializeScriptManager(manager);
		manager.addScriptModule("com.some.module", new SomeClass(tagProvider));
	}

The big thing in different contexts will be limiting behavior, probably by creating a specific interface to the common code from each context.

7

Turns out you can actually do what I originally asked…

First, you create whatever functionality you want in the Gateway Scope:

public class AwesomeGatewayFunctionality implements GatewayFunctionalityInterface {
    // ...constructor(s), function(s)
}

And expose that class like this in your Gateway hook:

	@Override
	public Object getRPCHandler(ClientReqSession session, Long projectId) {
		return new AwesomeGatewayFunctionality(context);
	}

Next you define an interface in your common code to the functionality you want to ultimately expose outside the Gateway Scope:

public interface GatewayFunctionalityInterface {
    public void greatFunction();
    public void soSoFunction();
}

And finally, add the module in your Client and/or Designer hooks:

	@Override
	public void initializeScriptManager(ScriptManager manager) {
		super.initializeScriptManager(manager);
		manager.addScriptModule("com.awesomeinc.pythonawesome", ModuleRPCFactory.create (ModuleMeta.MODULE_ID, GatewayFunctionalityInterface.class));
	}
2 Likes