I know it's been talked about a lot here (I did my homework before posting this). But I have a few questions about view property "Invalid key" warnings that appear when binding a property to a memory (document) tag that has keys with spaces, leading numbers, etc.
2- Is there a "best practice" or a recommended workaround when dealing with this issue in Perspective? Provided that "sanitization" (e.g. _1388_RH_CELL) is not an option as those exact cell names are used in dozens of different locations across the projects and the gateway. Referencing the tag directly seems to work flawlessly though but I'm concerned about having dozens of subscriptions to the same tag and the unnecessary overhead they may entail.
3- I know I can create a mapping (or keySanitize()/keyDesanitize() functions) but wouldn't that require a transform on every single property that references that data? I seem to have an allergic reaction to using transforms unless absolutely necessary (I know I probably view them to be way more costly than they really are, but I have a lot of old/low-end clients like TV browsers and tablets, so my concerns may be valid).
I'm currently using the neat, concise, single line expression binding from the previous screenshot, but at what cost?
Both. Because it is natural for tag names to be used as key names in many cases.
The warnings are there because the result produces invalid JSON, which cannot be reliably transmitted to the client browser. If you marked that property as "private", then it won't go to the browser, and you can ignore those warnings.
I still maintain that spaces are perfectly fine within tag names - I've been using them for 10+ years now. The only issue I've ever come across is when I (mistakenly) tried to bind a prop to a UDT instance; the keys which hold the tag values then have spaces in them which are invalid. However I'm vehemently opposed to binding directly to a UDT instance, so that issue for me is moot
