Output Param in Flex Repeater Missing

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.

1 Like

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.

1 Like