Hi,
we are trying to refresh local variable value on var change but it is not working. PFB Code
a!localVariables( local!refreshOnVarChange: false, local!allMessages: a!refreshVariable( value: rule!DS_QRY_getMessageThread( returnDatasubset: false, filters: a!queryFilter( field: "clientInboxId", operator: "in", value: {15,16} ) ), refreshOnVarChange: local!refreshOnVarChange /*refreshAlways: true, even in this case data is also not get refresh*/ ), local!textBox, a!sectionLayout( contents: { a!textField( value: local!textBox, saveInto: { local!textBox, a!save(local!refreshOnVarChange, not(local!refreshOnVarChange)) } ), a!textField( value: length(wherecontains(true,index(local!allMessages, "isRead", ""))), readOnly: true ) } ))
Discussion posts and replies are publicly visible
Adding my experience here - as this is something I've been tempted to start a thread on as well.
What I've seen is that if you have a refresh variable that calls a rule which contains a!queryEntity(), it will not refresh automatically. Simply moving the query out of the rule and into the main refresh variable, resolves the issue. However, then you have duplicated code if other areas of the application use the rule to query data also.
I haven't exhausted the different scenarios here yet, but I was noticing this last while creating a small message board type app. The main interface makes a post with a!writeToDataStoreEntity(), I trigger the local variable to refresh by incrementing a reload counter used in refreshOnVarChange, and in no situation can I get it to refresh without pulling the query out of the rule and pasting it in the main refresh variable. Then, it works flawlessly.
Would love to hear some other experiences on that as well..
And I've been doing a little further testing this morning and was able to get this working with a!queryEntity() within a rule, in some situations, but mainly when a!localVariables() is not used.
Sounds like you might have some other stuff down inside your expression rule gumming up the automatic refresh.
Chris said:but mainly when a!localVariables() is not used
you need to remember two of the main default properties of the a!localVariables() behavior:
1) it does NOT act with "refresh always" behavior unless set manually (meaning it acts slightly more like legacy "load()" than "with()"...
2) it DOES default to a "refresh on referenced variable change" setting of TRUE - but this ONLY has any effect when a referenced variable is actually changed.
This all means if you're storing a!queryEntity results somewhere in the expression rule in an a!localVariables() variable, then it won't refresh unless you pass a token into the expression rule that acts as a "manually refresh" agent. This is easyish to do since you can just pass in an integer value like "ri!refreshCounter" etc.
As I noted, I hadn't exhausted my research on this exact functionality yet
It seemed odd to me that when I told the parent interface's refresh variable to 'refresh' and basically 'go get the latest value from the rule', it would not do so. In further testing, I confirmed we can make it refresh but this involves sending the reload counter (for refreshOnVarChange) down to the child rule also, meaning we have to modify a shared query rule with a new input just to allow it to refresh properly for this interface.
So, basically what we have here is a layer of local variables, where the parent layer won't force the child layer to refresh automatically unless the same manual refresh conditions are passed down to the child.
I will submit that this isn't exactly intuitive, this requires additional coding in any query rule which may be used under refresh conditions. Where I just want to tell the parent interface, 'go get me the latest value from the rule no matter what'.
I'd expect it would also work if you set "refreshAlways" to true for the refreshVariable used in the rule.
Mike Schmitt said:I'd expect it would also work if you set "refreshAlways" to true for the refreshVariable used in the rule.
That does in fact work within the rule - confirmed. So we can bypass sending the reload counter input at least, but, still have to configure the child rule's a!localVariables to refresh themselves, in any situation where you are trying to refresh parent data from that rule.
yeah, that's about the size of it. to recap, afaik there are 4 mutually exclusive options/routes here:
In reality we'll need to decide between options 1, 3, or 4 depending on our use case (using 1 or not will automatically be determined by whether you need to use local variables in the first place). There are pros and cons to both 3 and 4 - and it'll always (afaik) depend on the use case; neither way is "right" or "wrong".