Configuring Perspective Flex Repeaters from Custom Objects

A single Perspective label bound to view.custom.siteData cannot show every property of that object. A label renders one line of text, so binding it to a whole object gives you a serialized blob or nothing useful. To get one header-plus-value pair per property, generated automatically, you need a component that repeats a child view: a flex repeater fed by a transformed instances array, or a table with a cell render view that performs indirect tag binding from a tag path column. Both work. Pick based on where the values live and how the screen should look.

Which component should repeat the siteData properties?

The screen needs N header/value pairs, where N is the number of properties in siteData. Something has to multiply a template by N. On a working screen, a flex repeater usually does this: it takes an array and stamps one embedded view per element, sized to the number of rows in its source.

For the tile layout shown on the target screens, build the flex repeater first. The table route is covered further down because it handles tag-path lists with less scripting.

Check before moving on: open view.custom.siteData in the property editor and confirm it is an object with the property names you expect as headers. If it is an array or a dataset, the transform in the next step changes.

How do I turn view.custom.siteData into repeater instances?

A flex repeater does not iterate object keys. It iterates an array in props.instances, and each element's keys are passed to the child view as params with the same names. So convert the object into an array of {name, value} pairs.

1. Select the flex repeater and add a Property binding on props.instances pointing to view.custom.siteData.
2. Add a Script transform:

   def transform(self, value, quality, timestamp):
       rows = []
       for key in value.keys():
           rows.append({"name": key, "value": value[key]})
       return rows

3. If siteData holds tag paths rather than values, emit the path instead: {"name": key, "tagPath": value[key]}. The child view then resolves the live value itself (next sections).
4. Set props.direction to row for side-by-side tiles or column for stacked rows.

Because the binding is live, any runtime write to siteData re-runs the transform and the repeater re-stamps its children.

Check: expand props.instances in the property editor. It should show one array element per siteData property, each with a name key and a value or tagPath key. If the array is empty, the transform is erroring. Look at the red binding indicator and the designer output console.

How does the child view receive the header and value?

Create the child view and point the repeater's props.path at it. Inside the child, declare input params whose names match the instance keys exactly:

Key matching is case-sensitive. An instance key of Name will not populate a param called name. The param keeps its default, and every tile shows the same default text. When the operator sees identical headers on every tile, the repeater is working and the key names are wrong. When the operator sees no tiles at all, the repeater has no instances.

Check: in the designer, preview the parent view. Each tile should show a distinct header matching a siteData property name.

How do I make the value label follow a tag instead of a static value?

If the values have to track live tags, pass the path and let the child view bind indirectly. This keeps the tag subscription inside each child instance, so adding a property to siteData adds a subscribed tile with no extra configuration.

1. On the value label, add a Tag binding and select Indirect.
2. Enter the indirect path as {path}, then add a reference named path bound to view.params.tagPath.
3. If only part of the path varies (for example, a site folder), build the rest of the string in the indirect path and substitute only the varying segment.
4. Leave the binding unidirectional unless the operator needs to write from this label.

Separate tag faults from binding faults when the value label misbehaves:

Check: hover the value label in preview and read the resolved path in the binding. Paste that path into the tag browser. If it resolves there but not in the label, the fault is in the binding. If it does not resolve, the fault is in the tag path data.

When is a table with a cell render view the better build?

When the source is a list of tag paths, with a dataset tag or an array of rows each carrying a tag path column, a table with a cell render view reaches the same result with less plumbing. The table already iterates rows. The render view only has to resolve one path per cell.

1. Feed the table props.data with rows containing a header/name column and a tag path column.
2. In props.columns, configure the tag path column's render as a view and point it at a small embedded view.
3. In that embedded view, declare the params the table passes into cell views (the cell value and the full row object). Bind a label with an indirect tag binding whose reference is the param holding the tag path.
4. Keep the header column as plain text, or render it through the same view if it needs styling.

Pick the table when operators need sorting, filtering, or many rows in a fixed grid. Pick the flex repeater when the layout must match tile-style screens with the header above the value.

Check: preview the table and confirm each row's rendered cell shows a different live value. Then change one source tag and watch only that row update.

How do I prove the whole screen end to end?

1. Launch a session (not only the designer preview) and count the tiles or rows. The count must equal the number of properties in view.custom.siteData, or the number of rows in the source.
2. Confirm every header matches its property name, with no duplicates and no default param text.
3. Write a new value to one source tag and confirm only its tile or row changes, within the tag's scan or subscription rate.
4. Add a property to siteData, or a row to the source dataset, at runtime. A new tile or row must appear without editing the view. This proves the binding is automated end to end.
5. Point one entry at a nonexistent path and confirm that tile alone shows the bad-quality overlay while the others stay good. That isolates tag faults per instance.

FAQ