Parameters are sometimes resolved in contexts where the parameter value is used as a literal string, such as an argument passed to a Java operator. On the other hand, many parameters are resolved in the context of an expression, such as in the Additional Expressions grid of a Map operator. To be considered a string when resolved in an expression context, parameter values must be quoted in the expression to prevent them from being interpreted as field names or other stream component names.
It is a best practice to use the following string quoting policy:
-
When defining a parameter, do not add quotes as part of the value's definition. For example:
-
When assigning a default value in the Parameters tab of the EventFlow Editor, specify a parameter as a simple string without quotes:
abcde
, not"abcde"
. -
When defining an
operatorParameter
in a server configuration file, use only the quotes required by the HOCON syntax. Do not add escaped quotes or single quotes within double quotes:operatorParameter = {ParamName = "Value"}
-
-
In expressions, place quotes around the parameter reference
${param-name}
when you want that parameter's value to be resolved as a string. For example:-
To use the value of
operatorParameter = {starter = "hundred"}
as a string in an expression, reference the parameter as:"${starter}"
. -
By contrast, to use a parameter value as a number in an expression, do not surround the parameter reference with quotes. Thus, you would reference
operatorParameter ={start = "100"}
as${start}
.
-
This policy places the expression-required string quoting in the expression itself, and not in the definition of the parameter. This separation of quoting contexts allows you to use the same parameter value in both expression and non-expression contexts.
Previous StreamBase releases suggested using single quotes within double quotes in the definition of parameter values that will be resolved as strings:
DO NOT USE -- NOT RECOMMENDED! <operator-parameter name="MyParam" value="'Value'" /> DO NOT USE -- NOT RECOMMENDED!
This practice worked when the parameter was resolved in expression language contexts,
but did not work in other contexts. In an expression, the value of parameter
${MyParam}
was extracted as the seven
characters 'Value'
, which means the
string arrived in the expression with quotes already in place. But non-expression
contexts that expected to receive the five characters Value
would result in an error when receiving the
seven characters 'Value'
.