I came across a bug where updating values are not flowing down to the subviews properly.
Below is a description of the configuration:
a Memory Tag of type “Document”
a timer gateway script that is updating a counter ever second and writing to the memory tag
a View using a Flex repeater with a binding from the tag to the “instances” property
a transform script generating the structure under “instances” to enumerate the subviews in the Flex Repeater
the View also using an embedded view with a binding from the tag to the “viewParams” property
a transform script generates the structure under “viewParams” for the subview
the subview displays the data through labels bound to the Params
Issues:
In the views from the FlexRepeater, the number associated with a key “01” does not update except when the page is loaded for the first time; even a page refresh does not update the values. NOTE: the number associated with the key “aa” does update with the data source.
On first load of a page, neither of the numbers in view from the EmbeddedView updates.
After refreshing the page, the number associated with key “01” does not update. NOTE: refreshing the page fixes the number associated with key “aa” and it begins updating similar to the flex repeater subview.
Below is a screenshot after First Load showing:
the value of the tag
the value of the “Instances” property of the flex view
the subview from the flexview container
the value of the Params property of the Embedded view
*the subview from the embedded view container
For issue #1, I’m suspecting this has something to do with the key being interpreted as an integer, which the Designer is flagging as an “Invalid Key”
For issue#2, this seems to be a difference between FlexView and EmbeddedView on whether parameters that are changing are flowing properly on first load.
I think I’m seeing a similar issue (#2), the Flex Repeater seems to update fine when there are 1 or 2 instances, but anything greater it will not update the other instances. I’m using the View Parameter change script to update the view based on the instance parameter value. I’m using 8.1.1.
Confirmed by adding a system.perspective.print() in the change script…
I’m using a Tab Container which has a Flex Repeater in it…
Update:
On further testing (in the designer), observed the following:
It SEEMS to update the same # of instances as the last update…so when the Flex Repeater updates if the new # of instances is > last # of instances, only the last # of instances is updated. I also tested going between 1 and 3 instances and noted that if 1 is shown, on update to 3 only 1 (1st instance) is updated, but if there were 3 on update 1 or 3 instances worked fine…
Could someone who is encountering this supply (all of) the relevant views they are using? This appears to be working for me, but it’s not clear what steps like a transform script generating the structure under “instances” to enumerate the subviews in the Flex Repeater mean because the script was not provided.
@cmallonee Attached is a View and Subview for the FlexRepeater and EmbeddedView components. It also includes a script that is feeding data into a memory tag, which I have being called from a Gateway Timer Event every 1000ms.
If you point your Perspective URL mount point to the FlexView, you should see how the values update or not update for the various configurations of FlexRepeater, EmbeddedView, alpha key and numeric key.
Between Daycare closures and ICC I have not had the time required to dig into this. Today is the first time I’v been available and have now begun. Your file is missing several components which I will need to put in place by hand (tag, Gateway Timer Script), so it’ll still be awhile.
Could you please provide some insight into the shape of the Tag in use and the Gateway timer script? I’m aware I requested the script because it was unclear what the script did, but without understanding what the script is acting on I am also at a disadvantage as to what could be causing your issue. It’s always better to provide us every resource in play when you are encountering an issue.
Not especially, because I still have no insight into the expected structure of the tag and or its values. The transform seems to expect that the tag is a list of integers, but any list of integer values which is not contiguous on sort results in the binding breaking ([0,2] will break, as will [0,1,3]). Then, when I examine your script which is being used in the timer script, I find that it’s writing to the tag as if it were a Document tag.
I’m afraid at this point that you’ll need to contact support for further assistance because the setup to replicate this issue requires more time than I can allocate at this point in our release schedule. Please provide support with the most recent .zip file, as well as an export of the tag you are using.
Hmm…this is just a throw-away project for the sole purpose of recreating the bug.
The gateway script on a timer is generating data to put in the tag; the tag is just acting as a placeholder for the script’s output data. All the script is doing is incrementing the values within the “document” to write to the tag. The script overwrites any data previously within the tag every time the script is called.
The view included in the project is using the data from the tag to display on the perspective screen. The only thing I was unsure of is whether importing my project zip file actually creates the tag. If it doesn’t, just create in your Default Tag Provider a brand new blank memory tag called “New Tag” with datatype Document.
The Gateway script with the name of the tag as a parameter:
The data in the tag should look like this:
Here’s what the perspective screen looks like in the browser
The bug to watch for is that the integer associated with the “01” does not increment within the flexview or the embeddedview, whereas the integer associated with the “aa” does increment. You will see them incrementing on the “DirectTagValue” or “FlexViewInstances” or “EmbeddedViewParam”. All the labels are pointed to the same data, but passing the data through a parameter with a “01” as a key is breaking the binding somehow.
If none of that works or make sense, let me know and I’ll call support.
Project exports do not include tags, because tags are Gateway-scoped - that is, Tags belong to the Gateway and are available to all projects. Any Tag content needs to be exported separately from the Tag Browser or I believe you can also export from the Gateway.
If you import my ZIP, then simply create a new memory tag called “New Tag” into your default tag provider with datatype document, do you see the values updating? It’s my understanding that there is no other work required.
I think Perspective itself enforces a non-numeric rule for keys, regardless of whether they were supplied as strings.
Consider the following onClick script:
self.custom.mine = {"1": 1, "01": "01", 2: 2}
Once that executes, you’ll see the following in the Property Browser (note that al three keys are designated as invalid):
The actual json of the view has wrapped even the numeric 2 value as a string:
# this snippet belongs to the Button which invoked the onClick event
"root": {
"children": [
{
"custom": {
"mine": {
"01": "01",
"1": 1,
"2": 2
}
}
So it seems that Perspective itself will refuse to honor keys which are numeric values. I would expect that any key which would not error out due to a ValueError if cast as float(some_key) would result in the issue you are seeing.
No, we did this for a reason. While JSON allows for some weird values for keys, you must also consider how this JSON used in Perspective interacts with other pieces of ignition. We discovered early on in the development of Perspective that while some JSON key values were valid they wreaked havoc with other systems. I had forgotten that numbers were one of those, with spaces being the primary driver behind a tighter restriction of what it means to be a valid key in Perspective.
The most common problems we encountered was when we tried to interpolate these key values while resolving indirect tag bindings and expressions; spaces would result in broken paths and numbers in some instances would resolve to attribute names of internal Java objects, even though Java does not allow for such attributes/variables.
