I feel like this question has been answered somewhere, but I'm striking out with my searches.
I have a template repeater set to "Count" for the repeat behavior and I want to pass a tag path string as a constant to each template instance so that I can use it in conjunction with the count index parameter. I know I can switch to "Dataset" for the repeat behavior with a script to dynamically generate the dataset with the tag path included, but that seems rather heavy handed for this. What I have been doing instead is setting up a custom tagPath template parameter on the repeated template and using a runScript() expression to access a custom tagPath property I created on the template repeater object via:
# There are 3 'hidden' layers between a template instance and the repeater object
runScript("self.parent.parent.parent.parent.tagPath")
So far it has been working great while keeping screen designs very simple and easy for others to follow. My assumption has been that this type of runScript expression should run fast enough to not be an issue, even if running on multiple objects at the same time. But I want to get input from others here to see if I'm playing with fire by having a runScript like this in every template instance. Thanks in advance!
Eww! Just use dataset mode.
2 Likes
Not what I was hoping to hear 
Ignoring the eww factor, in general, would there be any concerns around performance with this approach? Or would grabbing a property value always be fast enough to not have to worry about performance?
Yes; chronic use of runscript expressions can harm performance. I imagine this would be amplified when used in a repeater which requires more overhead than most components. The dataset option is the preferred method for what you are describing.
Edit: Improved wording
2 Likes
Good to know. I was hoping that since the runScript would only run once when the template was loaded, and was only grabbing a property value, that it might have similar performance to any other bindings within the repeated template instances - but it sounds like that isn't the case.
I don't typically avoid the dataset approach, but here it just felt messier. A little more background on why. We have popup windows that have a number of embedded templates, with a subset of those templates having embedded repeaters. Some of those repeaters are driven by simple "Count" behaviors while others are already using the "Dataset" behavior and are bound to a static dataset memory config tag that is defined as part of a device UDT. For all of these repeaters, they require the tagPath property to function. The dataset memory config tags are mostly defined by the UDT default value and this config tag only needs to be overridden for a portion of the UDT instances. Dynamically embedding the tagPath value into the config tag UDT definition is something I've avoided since that would really overcomplicate the UDT. This leaves running a script on the popup window to generate datasets in place of the "Count" behavior templates and another script to add the tagPath column to the config dataset - while navigating the headaches with the timing of property binding updates when running the scripts.
It's all stuff I've certainly done before. It just feels heavy handed when all that I need is to access the same tagPath string value in every template within the popup window. That's when I started testing out alternatives and ended up down this rabbit hole...don't worry, I'll bury my runScript idea and switch back to scripting the datasets. 
It would be nice if there were a cleaner approach to passing in (broadcasting...?) a single value to all template instances within a template repeater...
Consider dynamically generating the dataset from the count with my Integration Toolkit. Something like this:
unionAll(
asMap('index', 'I', 'tagpath', 'str'),
forEach(
{Root container.path.to.count},
idx(),
'[default]some/constant/tagpath'
)
)
No jython required.
2 Likes