Recently I've been working on parsing for issue #704. Firstly I was trying to improve the parser so that it can more reliably detect instance expressions, before we roll it out to being supported in more places, because any deficiencies in parsing would become more likely e.g. #844. I was able to implement something that seemed pretty good but it is very slow, like second(s) per string slow, and worst case forms can have many thousands of strings. The main problem is that an instance expression can involve almost any valid XPath 1.0 content. With no delimiter around the expression, the parser has to resolve a non-trivial amount of ambiguity in chaining up the parsed tokens.
I think implementing something like f-string or jinja syntax is a good solution. That syntax is two curly braces on either side of the expression to be processed. For example "This is my {{ instance() }} expression". That way the parser can work in two stages instead of doing both at the same time, i.e. 1) find delimited expressions 2) replace and/or process the expression. This approach would allow future enhancements like allowing arbitrary expressions to be templated in strings (not just instance() expressions).
At the moment users must put expressions e.g. in a calculate item, then use a ${item} reference to template it. A side benefit of the calculate approach is controlling when the expression is evaluated. Still, allowing display-only expressions could be very useful especially for forms with lots of hidden calculate items where the stored value isn't needed for anything e.g. extra data being transmitted/parsed/processed which is filtered out later in form data analysis.
Also possibly relevant: #704, or the ${} references labelled issues.
Recently I've been working on parsing for issue #704. Firstly I was trying to improve the parser so that it can more reliably detect instance expressions, before we roll it out to being supported in more places, because any deficiencies in parsing would become more likely e.g. #844. I was able to implement something that seemed pretty good but it is very slow, like second(s) per string slow, and worst case forms can have many thousands of strings. The main problem is that an instance expression can involve almost any valid XPath 1.0 content. With no delimiter around the expression, the parser has to resolve a non-trivial amount of ambiguity in chaining up the parsed tokens.
I think implementing something like f-string or jinja syntax is a good solution. That syntax is two curly braces on either side of the expression to be processed. For example "This is my {{ instance() }} expression". That way the parser can work in two stages instead of doing both at the same time, i.e. 1) find delimited expressions 2) replace and/or process the expression. This approach would allow future enhancements like allowing arbitrary expressions to be templated in strings (not just instance() expressions).
At the moment users must put expressions e.g. in a calculate item, then use a ${item} reference to template it. A side benefit of the calculate approach is controlling when the expression is evaluated. Still, allowing display-only expressions could be very useful especially for forms with lots of hidden calculate items where the stored value isn't needed for anything e.g. extra data being transmitted/parsed/processed which is filtered out later in form data analysis.
Also possibly relevant: #704, or the ${} references labelled issues.