String Values in Parameters

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.

Suggested String Quoting Policy

TIBCO recommends 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 <operator-parameter> in a server configuration file, use only the quotes required by the XML syntax. Do not add escaped quotes or single quotes within double quotes:

      <operator-parameter name="MyName" value="MyValue"/>
      
  • 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 <operator-parameter name="starter" value="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 <operator-parameter name="start" value="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 Releases

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'.