You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The question came up in today's call about fields that could take either a literal value or a runtime expression. The parameters field in the Link Object allows this. Probably we should clarify that anything that parses as a runtime expression SHOULD (MUST?) be handled that way, and that it's therefore not possible to specify a literal value that looks like a runtime expression (since creating an escaping syntax would require a minor version increment).
There's a further ambiguity: the property names under parameters are either parameter names or qualified with the parameter's in field, e.g. path.id vs query.id. Parameter names are strings without any restrictions other than that imposed by their locations, and . is a valid character in at least the path and query parameter names.
In this case, there's an easy solution which is that if you (for some bizarre reason) have a parameter named path.id, then to reference it you would always qualifiy it (path.path.id, or I guess if you're particularly mind-bending ,query.path.id).
The question came up in today's call about fields that could take either a literal value or a runtime expression. The
parameters
field in the Link Object allows this. Probably we should clarify that anything that parses as a runtime expression SHOULD (MUST?) be handled that way, and that it's therefore not possible to specify a literal value that looks like a runtime expression (since creating an escaping syntax would require a minor version increment).cc @webron @mkistler
The text was updated successfully, but these errors were encountered: