After the gateway resolves the intended view as a project resource and supplies a compatible parser from the same runtime context, ViewConfig can expose the view’s parameter definitions for XML export. Initializing Gson alone does not solve a missing, wrong, or inaccessible ProjectResource, and getParamDefinitions does not automatically represent every permission associated with a view.
Where does the view-data path stop?
Follow the request from the Gateway-scoped caller to the result: gateway code selects a project and view, obtains the corresponding ProjectResource, passes that resource and Gson to ViewConfig.fromProjectResource(ProjectResource resource, com.inductiveautomation.ignition.common.gson.Gson gson), calls getParamDefinitions, and serializes the selected fields to XML. The first missing or incompatible object stops the path.
| Hop | Reading to take | Pass condition | Failure meaning |
|---|---|---|---|
| Gateway caller | Execution scope and project identity | Code runs in Gateway scope against the intended project | The caller cannot see the expected gateway project context |
| Resource lookup | Resolved resource path, name, and existence | The object identifies the intended view resource | The failure precedes JSON parsing |
| Resource content | Presence and readability of view.json
|
The resource contains nonempty view configuration data | The lookup returned the wrong resource, an incomplete resource, or no readable content |
| Parser | Gson class identity and runtime context | The instance is accepted by fromProjectResource
|
Type, class-loader, module-context, or adapter compatibility is wrong |
| Configuration | Returned ViewConfig and parameter collection |
The object parses and getParamDefinitions returns the expected definitions |
The JSON shape or selected resource does not match the parser’s expectations |
| XML output | Element count and representative values | Exported values match the source view | The extraction or XML mapping dropped, renamed, or escaped data incorrectly |
Does the storage layer contain the intended resource?
Layer one is the project storage layer, not Gson. The working path-based approach proves that a view.json file can be read from the gateway’s project directory, but it does not prove that the ProjectResource passed to fromProjectResource represents that same file. Record the project identifier, view identifier, resolved resource identity, and content size before testing deserialization.
| Field | Reading for this path | Engineering consequence |
|---|---|---|
| Address | Gateway project-resource identity or local project path | This is a local resource lookup; validate the selected project and view rather than an IP address |
| Port | Not part of the stated data path | Do not troubleshoot firewall or socket settings unless another component actually moves the data over a network |
| Timing | No exact timeout or polling interval is specified | Measure lookup and parse duration only if the operation stalls; do not invent a timeout value |
| Setting | Gateway scope | Resolve resources through the gateway’s active project context |
Test the raw content read and the resource-object read against one known view. Compare stable markers such as the view name and declared parameter names. If they differ, correct resource selection before changing Gson. If the resource object has no readable view.json content, inspect the project-resource structure presented by the gateway rather than treating a filesystem directory as the resource itself.
Is the object really the required ProjectResource?
fromProjectResource accepts a ProjectResource, not a file path and not an arbitrary JSON string. That distinction carries project metadata and the resource’s stored data into the conversion. Passing an object that merely points near the view directory can fail even when direct file access succeeds.
- Select one existing view with a small, known parameter list.
- Resolve the view through the gateway project-resource mechanism and log its identity without logging sensitive configuration values.
- Confirm that the resource contains the expected
view.jsondata. - Call
ViewConfig.fromProjectResourceonly after those checks pass. - If parsing fails, capture the complete exception type, message, and cause chain. A missing resource, rejected argument type, and JSON conversion error lead to different branches.
A null result or resource-not-found condition returns the investigation to project selection. A type error points to an incompatible object or duplicate class definition. A JSON conversion error moves the investigation to Gson configuration or configuration-schema compatibility.
Is Gson compatible with the ViewConfig parser?
The declared parameter type is com.inductiveautomation.ignition.common.gson.Gson. Compatibility therefore means more than constructing an object named Gson: the instance must have the expected type identity and the adapters required by the Perspective configuration model. Module systems can load identically named classes through different class loaders, making them incompatible at runtime.
PerspectiveModule.createPerspectiveCompatibleGson() was attempted without success. Treat the resulting exception as the decision point:
| Observed failure | Likely layer | Next check |
|---|---|---|
| Method or class cannot be found | API exposure or runtime context | Verify that the caller can access the Perspective module API in Gateway scope |
| Argument-type mismatch | Class-loader or Gson-type mismatch | Compare the fully qualified runtime class of the created object with the method’s declared parameter type |
| JSON conversion exception | Missing adapters or incompatible resource schema | Confirm the resource first, then obtain the parser through the Perspective-owned runtime context |
| Valid configuration with wrong values | Wrong project resource | Compare the selected view and its known parameters |
Do not substitute an unrelated generic Gson instance merely because its basic JSON parsing works. A configuration model may depend on registered type adapters that generic parsing does not provide. If the compatible factory is inaccessible from gateway scripting, move the conversion into supported gateway-module code or keep the proven raw-JSON reader and validate its schema explicitly.
Do parameter definitions also contain permissions?
getParamDefinitions names its boundary: parameter definitions. It is the correct extraction point for declared view parameters, but it does not by itself establish where view permissions are stored. Treat parameters and permissions as separate export branches until inspection shows that both belong to the returned configuration object.
| Export branch | Read from | Validation |
|---|---|---|
| Parameters | ViewConfig.getParamDefinitions |
Compare names, direction or access metadata, and defaults that are actually present |
| Permissions | The specific access-control structure found in the project resource or parsed configuration | Compare against a view with a deliberately known restriction |
| XML mapping | Explicit fields from each branch | Check counts, values, escaping, and absent optional fields |
Do not infer permissions from parameter access semantics. A parameter’s input/output behavior and authorization to open or use a view solve different problems. Locate the permission-bearing structure by comparing otherwise similar views with different access settings, then export only the field whose value changes with that setting.
How should the resolving branch be implemented and verified?
- Choose a controlled view containing known parameter definitions and a known permission difference.
- Run in Gateway scope and resolve that view as a
ProjectResource. - Confirm that the resource contains the intended
view.jsoncontent. - Obtain the Perspective-compatible Gson object from the same gateway/module runtime context as
ViewConfig. If scripting cannot access a compatible object, use gateway-module code or the existing raw-JSON method. - Invoke
ViewConfig.fromProjectResource, reject a null result, and capture the full cause chain for any exception. - Call
getParamDefinitionsand map only observed fields into XML. Extract permissions through their separately identified configuration structure. - Escape XML-reserved characters, represent missing optional values consistently, and write to a separate output file rather than modifying
view.json. - Parse the generated XML back into an XML reader, compare parameter and permission counts with the controlled view, then repeat against a second view to detect hard-coded resource selection.
FAQ
Why does ViewConfig.fromProjectResource fail when view.json is readable?
A readable file proves only the storage path. Confirm that the supplied ProjectResource contains that same view.json, then classify the exception as lookup, argument-type, or JSON-conversion failure.
Why does a new Gson object not parse an Ignition Perspective view?
The method declares com.inductiveautomation.ignition.common.gson.Gson, and the configuration model may require Perspective-specific adapters. Check the runtime class identity and obtain the parser in the same module context as ViewConfig.
Why does PerspectiveModule.createPerspectiveCompatibleGson() still fail?
The failure can occur before parsing because the factory is inaccessible in that scope, because class loaders disagree, or because the supplied resource is wrong. The complete exception and cause chain identify which branch to follow.
Why does getParamDefinitions not return view permissions?
getParamDefinitions returns parameter definitions. Find the separate access-control structure by comparing two views with a known permission difference, then map that structure independently.
How do I verify a view.json-to-XML export?
Parse the XML back, compare parameter and permission counts and representative values with the controlled view, and rerun the export for a second view to verify that resource selection changes correctly.