New "SmartIntepolation" expression property

Context

This feature request is capturing the requirement from AdaptiveCard team’s templating library, which depends on adaptiveExpression.

Original Requirement

The expected user experience in AdaptiveCard templating library is

• when user input is a simple variable, like ${name} or ${age}, it should evaluate as a single variable and the return type is the variable type (int\float\string, it could vary)
• when user input is text + variables, like ${age} is too big, it should evaluate as a string intepolation, and always return a string type

Current AdaptiveExpression Design

The AdaptiveExpression library doesn’t offer a straight solution to the specific requirement above. AdaptiveExpression, as a generic expression library, is designed to support for a wider scenarios with some basic primitives and rules like

• basic expression: foo, bar, will evaluate to the variable
• string interpolation expresssion: `${foo}` or `${foo} is good` will evaluate as string, this is consistent with many other programming languages.

Current Solution

To bridge the AdaptiveExpression’s design and AdaptiveCard templating’s requirement, the current solution been implemented, is let the caller (AdaptiveCard) to inspect the parsed result of a string interpolation expression. And do a customized evalution based on it.

• if it’s a string interpolation with only one children, and the children is a varaible ref. Evaluate directly against with the variable without converting to string.
• otherwise, evaluate as string intepolation

Issues

AdaptiveCard now depends on the parsed structure (AST) of a string interpolation expression. This parsed structure changes a little bit during 4.10 to 4.11 (to fix some corner case issues), which then break adaptiveCard team’s assumption and break the end users as well.

From AdaptiveCard’s POV, a native solution will requires less integration effort, and thus less risk to break. From AdpativeExpression’s POV, we don’t want to user to depends on AST (which is considered as a internal implementation) for some common requirements.

Proposed Solution

Create a new ExpressioProperty for this scenario

In AdaptiveExpression, we have built a layer called “ExpressionProperties” on top of basic expression layer to offer some extra tranform, processing and convenience mostly for AdaptiveDialog. There is StringExpresion, FloatExpresion, ObjectExpression, etc.

It make sense, in this layer, to create a new “SmartIntepolationExpression” to accept the expected input and deliver a smarter typing, basically implement the requirement inside AdaptiveExpression.

Thus AdaptiveCard team will have less integration code and most importantly no longer depends on “internal implementations” of adaptiveExpression.

The pro side of this solution is it made the integration easier by offering more features. The down side is it brings more effort and concept to adaptiveExpression.

[boydc2014]

@boydc2014 when you implement this in C# can you tag @joshgummersall and myself to have a chance to review? Thanks for putting this proposal together!

Sure, this is still a DCR now, and you can see Chris on below is suggesting a new function instead of a new ExpressioProperty.

The pro of a new function is it will very light-weight, simple and easy, with minimal maintenance effort and get this feature widely available. The cons is we have very little space for caching, perf-tune or some reusability.

The pro of an ExpressionProperty is the reverse of a new function.

I prefer the function approach, since it’s light-weight, and most important it wouldn’t be a blocker for us to implement an expression property later (if for whatever reason we have to).

I will keep socializing this a little bit before moving into implementation.

[chrimc62]

I much prefer an explicit function, i.e. stringOrValue(‘${2+3}’) -> 5 and stringOrValue(‘woof is ${3+5}’) would produce ‘woof is 8’. This makes this functionality available everywhere in expressions. The implementation would be what Adaptive cards already do, i.e. treat as interpolated string and if a single child return that.