Performance. Template processing and regex parsing to find templates have a cost at scale so having an explicit config option for whether or not to do so shaves time off of startup and runtime. I’m kind of guessing there but I’ve been looking at some of Bdraco’s PRs and been constantly astounded by the performance cost of simple tasks.
Text that just happens to contain template characters. Anything is valid in a text field in these service calls so there’s no real way to automatically differentiate between a user that wants text processed as a template and text that just happens to contain characters like {{, }}, {%, etc. Or maybe even text that actually contains a template but you don’t want it processed as one, you want the text passed on with the template as is. The only way to accurately differentiate between these is to ask the user to tell them whether the text is a template or not via an explicit config option.
Now one enhancement I could see here is the automation/script editor UI could look at what you are entering as you type. If it sees a template and you are not using data_template the UI could show an info/warning container that says something like "it looks like you entered a template, did you mean to use data_template"? This I think would solve the same problem you’re trying to solve since the user is immediately made aware of the fact that their template is not going to be processed as a template. But since this processing is occurring at design time it doesn’t impact runtime or start up performance.
Thanks for for chiming in. I’m still thinking lthe correct place to accommodate this issue is in the backend / YAML, not in the frontend / GUI. That way, it is independent of the place where you enter your automation.
Performance might be be an issue, I can’t say. As for the “it might be text” argument, I think starting with {{ or {% is a good indicator of a template. If not, some escape characters might do the trick.