[IGN-15726]Project settings in Perspective 8.3 for components

[torstein]

Hi! We are making a module which add Ignition Perspective components (react components). For this we need some common settings, this could be badge handling, style type, etc.

So I have made a project property view in the designer:

But I haven’t found a good way to store the data and to get the data down to the component.

ChatGPT suggested to use model delegate to send the data from the gateway to the component.

I use this to set the data:

public ObComponentTypeProjectSettingsEditor(DesignerContext context) {
   super(new GridBagLayout());

   project = context.getProject();
   Optional<Resource> resource = project.getSingletonResource(RESOURCE_TYPE);

   if (resource.isPresent()) {
      try {
         settings = ResourceUtil.decodeOrNull(resource.get(), context.createDeserializer(), ObComponentTypeProjectSettings.class);
      } catch (Exception e) {
         log.error("Failed to decode ObComponentTypeProjectSettings", e);
         settings = new ObComponentTypeProjectSettings();
      }
   } else {
         log.error("Failed to get ObComponentTypeProjectSettings");
         settings = new ObComponentTypeProjectSettings();
  }


…

@Override
public Object commit() {
   settings.setComponentType((String) componentTypeDropdown.getSelectedItem());
   return settings;
}

I’m not sure if this works. But the naming of the functions seems promising (project.getSingletonResource) and I hope the commit function stores the resource.

But in the model delegate I have trouble accessing this resource. As the gateway context don’t have “context.getProject”.

So I need some guidance.

1. Is the suggested method to use resource and model delegate the correct way to get the project settings down to the component? Or should we use other methods?

2. How do I store and access this resource?

Thanks in advance!

[bmusson]

I'd create a small, Perspective-authenticated servlet that your client would call when loading.

1. Client starts, loads your BrowserResource.
2. Your BrowserResource queries your endpoint and is given the settings for the current project.
3. Store the settings globally in the client, and use as needed in your components.

[torstein]

That sounds smart. Like setting window.mymodule.style = "flat" and accessing that from the component? Would that work in the designer?

[bmusson]

@torstein

Like setting window.mymodule.style = "flat" and accessing that from the component?

Exactly.

@torstein

Would that work in the designer?

Yup, nothing special is needed in the designer.

This is how I handle it in Embr:

libraries/javascript/perspective-client/src/globals/globals.ts

Different modules add different things in that namespace as needed.

The only "gotcha" I've found is that you sometimes need to wait for the ClientStore to become available before you can reliably reference it.

modules/periscope/web/src/client.ts

main/libraries/javascript/perspective-client/src/utils/waitForClientStore/waitForClientStore.ts

[paul-griffith]

Ben also asked for the ability to provide session props in a module, which is something we should do, but no timeline on when:

[IGN-15726]Adding module-specific session properties

Is there any supported way of adding to the built in Session properties (i.e session.props, not session.custom)? I have some configuration stuff that would most naturally fit as session properties (to allow for binding support). I guess I can read/write to whatever session property keys I want, but I’d really like to provide schema information.

[torstein]

@paul-griffith for us we would like to have a project setting (which is the same for all sessions). I think I only need a guidance on how to store a setting from the "Project Properties" view in the designer (as shown above) and how to retrieve that setting in an Gateway endpoint.

[paul-griffith]

Yeah - to me, the "natural" way to do that that end users would have a good time with (if they need to bind to it or otherwise read it easily) would be a read-only session property that your module is in charge of providing.

Ben's workaround(s) are probably the best solution in the short term - he's got more practical experience extending Perspective than anyone else I'm aware of.

Our solution to the same problem first party is simple - we just made the requisite changes first party in the page loading, and didn't think about the use case of third parties needing to extend things.

[bmusson]

@paul-griffith

workaround(s)

100%, the way I suggested is just a work around.
At the moment the only thing easy about extending Perspective is adding components. Beyond that, it gets hacky pretty quickly.

@paul-griffith

read-only session property

I’d like to see the access be controllable.

Some properties would benefit from read/write (similar to session.props.theme), while others only need read access (similar to session.props.id).

[torstein]

I think I solved the project setting issue. But it feels very hacky

        String projectName = component.getSession().getProjectName();
        Optional<RuntimeResourceCollection> resourceCollection = gatewayContext.getProjectManager().find(projectName);
        Optional<Resource> resource = resourceCollection.get().getSingletonResource(ObComponentTypeProjectSettings.RESOURCE_TYPE);
        return ResourceUtil.decodeOrNull(resource.get(), gatewayContext.createDeserializer(), ObComponentTypeProjectSettings.class);

Is there a better way to get the project resource collection than:

Optional<RuntimeResourceCollection> resourceCollection = gatewayContext.getProjectManager().find(projectName);
        Optional<Resource> resource = resourceCollection.get().getSingletonResource(ObComponentTypeProjectSettings.RESOURCE_TYPE);

Now I'm depending on the naming convention of the resource collection. The code will fail, if the mapping between project name and collection name changes.