Ignition view template + popup

[lovro.sibenik]

I’m working on an Ignition Perspective project and I’m trying to build a clean, reusable architecture for device popups. I already have a generic popup template view that works correctly: it receives device data via parameters and displays all properties dynamically. The part that I’m struggling with is the controller view, which acts like a button and is embedded underneath a device element (for example, a Thermometer component).

My goal is to be able to drop this controller view under any device and connect it using only one binding/parameter, such as a deviceKey or taken_device_name. When the controller view is clicked, it should use that single parameter, resolve the corresponding device data, and open the popup template with the correct parameters. I want to avoid adding custom properties or scripts directly to the device components themselves, and I also want the controller/template to remain fully generic and reusable.

Currently, the popup side works, but I’m not sure how to design the controller logic so that the device can be resolved using only one parameter. My initial idea was to have the controller script “look into” the view it is embedded in, find the device by name, and then read its parameters. Since that is not possible in Perspective scripts, I tried creating a separate object (for example a devices object) on the parent/root view and passing it down to the embedded controller view, where the controller script searches it by taken_device_name. This works, but it requires additional bindings, and I was hoping to reduce the setup to just one binding.

I also considered putting the device object directly on the controller template itself, but I ran into the problem that you cannot directly bind properties between independent views (view‑to‑view binding is not supported unless it’s parent → embedded via parameters). So right now, I’m unsure what the cleanest and recommended approach is to connect a device to this controller using only a single identifier, while keeping the controller and popup fully generic and avoiding tight coupling to the view hierarchy.

I’m looking for guidance on the best practice here: how to structure the data model and bindings so that a controller view can resolve a device by name/key with minimal bindings, and then open a generic popup showing that device’s parameters.

[lane.duncan]

@lovro.sibenik

I want to avoid adding custom properties or scripts directly to the device components themselves,

Why? The gods at Inductive Automation have blessed you with all these fantastic tools, use them.

If you need commonality between different types of devices then use a project script called by the onClick event. Pass whatever you need to the script. Don't bury it in another view.

[lovro.sibenik]

@lane.duncan

Why? The gods at Inductive Automation have blessed you with all these fantastic tools, use them.

If you need commonality between different types of devices then use a project script called by the onClick event. Pass whatever you need to the script. Don't bury it in another view.

This approach is meant for a large, heterogeneous set of devices in a plant, where scalability and low maintenance matter more than wiring individual onClick scripts. The controller template is a lightweight abstraction so a user can drop it under a device, set a single device key, and immediately get a popup without duplicating logic across views. The goal is faster setup, less repetition, and a single place to evolve the logic as device types and requirements grow.

[pturmel]

Make the root of your controller and popups be a tagpath to the UDT instance. Include a document memory tag in your UDT containing the view path and params needed by the popup.