The Side Effect of Creating Repeat Controls at Runtime
In a recent post, I showed how to access the value of components within a repeat control from outside. While the technique served a great purpose in a recent application, there is a significant side effect that you need to be aware of before implementing a similar solution.
The technique described in the post requires all controls within the repeat to be created at runtime and dynamically but consistently named (based on the repeat index) so they can be programmatically accessed in a predictable manner.
I had a good discussion about this topic with Tim Tripcony and he pointed out that the side effect of the Create controls at page creation property of the repeat control is that all of the controls within the repeat are locked into place at page creation. This means that you cannot dynamically update the repeat control. A partial refresh won’t do it. A full refresh won’t even do it.
I saw this side effect in my application. In order to see any updates to the repeat control while the page is still loaded required context.reloadPage().
That’s still fine in my case, but it wouldn’t be fine in many cases where I use repeat controls, so please keep it in mind that setting that property will prevent you from being able to update a repeat control with a partial refresh.