I had a Flex Repeater with the instances array determined by a complex expression structure binding.
When the page loaded, all output params of the repeated view were present and set correctly.
When variables on the page changed, causing the instances binding to reevaluate, one of the output params on the view was consistently absent. It could be added back in the designer via Sync Params, but never appeared on a binding evaluation.
I eventually found that the one param that was missing had a property binding, and the other output params that were working had expression bindings.
I'm not sure why this was the case, but it consistently worked after changing the binding on the output param to expression.
Just leaving this here for my own reference, or anyone else who tries to search for it. If this is easily replicated, perhaps IA will consider fixing it as a bug?
Could you describe in a bit more details ?
I'm particularly interested in the relations between the repeated view's input parameters and the missing output.
When this happens, it's usually because nothing is generating the data for the output params. Do you get nulls with the expression binding method ?
I figured this out!
The templates being repeated had several inputs and several outputs.
The instances array was being generated by an expression structure binding that created an array, then appended to it dictionaries defining the input params for the instances.
This worked nicely, and populated the instances array, which would then create instances of the template, which would calculate its outputs, and add them onto their corresponding instance params.
However, some dropdowns on the page were inputs to the expression structure binding, and would cause it to reevaluate. This would overwrite the instances array, but often with only minor changes to the inputs to the templates. As a result, instances whose outputs did not recalculate did not reproduce their output params. So the outputs would disappear.
Outputs affected by the changing inputs would recalculate their bindings and reappear after their instance object was overwritten.
I think this is why changing my output bindings in the template worked before, because I had caused them to recalculate on different behavior.
It's quite interesting that the templates don't get created fresh when the instances array changes. It's also interesting that the template doesn't recompute all outputs when its inputs change, but only the outputs whose bindings are changed
That's the point of bindings: They're evaluated when the source changes. No change, no processing.
You explained the problem, but did not share how you fixed it.
I encountered this issue and I believe I added a message handler to the repeated view, which would simply call refreshBinding on what needed to be reevaluated, then sent this message when rebuilding the instances list.
I think I also used another way, which I don't remember right now... I'll see if I can find it.
The issue was also that there were multiple inputs to the template that were only referenced in a transform inside the template. Because the binding didn't reevaluate when the transform-only inputs changed, the template didn't update when it seemed like it should.
I ended up just setting the instances array to [] before the binding evaluated so the templates would all be regenerated on change.
You can use a structure binding to use multiple sources.
That's great for expressions, but not ideal for named query bindings
Make a custom property with your named query binding, then another custom prop with a structure binding that references the first prop.
I revisited this project, and Iâm not sure if this was what you were getting at, but I found another good way of forcing the output parameter to regenerate.
Use an expression structure binding for the output parameter.
Attach as âObject Membersâ the value you actually care about, as well as all the input parameters that might cause it to recalculate (Maybe all of them if youâre not sure)
Use a transform to pick out only the value you want to output. (script transform, something like âreturn value[âoutputâ]â
Because all the input params are referenced in the expression structure, the binding WILL recalculate when any input param changes, even though you throw them all away in the transform, outputting only the value you care about.
I'm not sure I understand.
You have a structure binding, using a and b as members.
You only want to return a, but included b to trigger refreshes.
Is that correct ?
If that's the case, that shouldn't be necessary. This would trigger refreshes even if a didn't change, and a simple binding on a should be enough to trigger refreshes when a changes.
I suppose there's a reason and this solves something, but what exactly ?