Vision Client Document Tag Alternatives

Ignition
,
1

So I know that document tags, or at least it seems this way, are not supported as a Vision Client Tag. Is there a good alternative? If I stored a JSON-friendly string into a client tag and then pulled data using the jsonGet expression, would that effectively be the same?

We are exploring being able to have multiple themes for our Vision applications, and the themes can get pretty involved with each visual device type having different options etc... So we are exploring creating a using a single JSON document that defines the theme, and then having each visual device look into that JSON document to determine what color it needs to be displaying.

I don't want to go down a road that we are going to regret once this goes live, so I'm asking now before I get into trouble lol.

2

Hmmm. The document type was added to Vision in 8.1.47 or .48 and I have tested it with custom component properties. Were Client tags overlooked?

Edit: Yup. Missing from client tags.

3

Yep. I see them as custom properties as well. I wish client tags had a document type... then this entire conversation is moot.

4

Did some poking under the hood. You can create a Document Vision Client Tag via the clipboard. Put this text into your clipboard:

<Tags>
   <Tag name="SomeTagName" path="" type="Client">
      <Property name="Value">{}</Property>
      <Property name="DataType">29</Property>
      <Property name="PollRate" mode="2">0</Property>
   </Tag>
</Tags>

Then paste into the tag browser while open to the client tags.

Caveats:

  • You cannot edit the content of the document from the tag editor. It doesn't understand the document type for Client tags.

  • You can bidirectionally bind a Document custom property to that tag and use the property's document editing ability to update the client tag.

5

Thanks!

I think that might get hairy... I tested loading a JSON string encoded with system.util.jsonEncode into a string client tag, and then binding to it with an expression like so: jsonGet({[client]Configuration/ThemeString},'Colors.testing') and it came back like I expected. I'm thinking in lieu of having a formal Document tag, this should work. Any major issues I need to be aware of? Size issues etc?

6

jsonGet() is absurdly inefficient. If you really want to use a string client tag, you should decode into a root container document property. Then you can use the native expression bracket operator to extract from that efficiently.

7

So if I have a bunch of templates to represent devices that need access to this data, would it be better to have a custom property on each of the templates that is bound to the string?

We are also exploring datasets as this is turning out to be something that will fit into a dataset. Originally we thought it might be a 3 dimensional lookup table, but we are trimming it down to a regular lookup table.

Right now we are scripting the color access though a convoluted runScript that just works, but doesn't give us the flexibility to make easy changes. I was hoping a document tag, but it looks like that might not work at the moment.

Could I potentially load a JSON into global using your system.util.globalVarMap and then read it back out as a binding from globalVarMap expression?

IE something like (pseudo-code):

theme = {'color1':'#fafafa'}
bvm = system.util.globalVarMap('theme') = theme
bvm.refresh()

And then retrieve it as an expression as:

globalVarMap('theme') - Not sure how to get the color1 part of the dict here if even possible.
8

Yes. Reference like so:

globalVarMap('theme')['color1']

1 Like
9

And I can overwrite the keys as required during runtime?

This might be they way to go.

10

Yes. And if you call the refresh method on the gvm, any expressions using that gvm will re-run.

2 Likes