"Nesting" Tokens
Because the token is a placeholder that gets resolved at runtime, it's possible to make token identifiers dynamic. This is done by making part of the token identifier itself a token. Consider this token construction:
@Request.@Local.VarName~~
Notice that it has two @ signs and two tildes. For clarity in understanding how it's processed, imagine there are parenthesis in there, like this:
@Request.(@Local.VarName~)~
As you can probably now guess, when the report runs, the "inner token" (inside the parenthesis) is resolved first, then the "outer token", which now includes the literal value of the inner token as its identifier. So, for example, if:
- A Local Data element returns data in a column named VarName, value = "Mode", and
- A Request variable exists named Mode, with a value of "Standard"
Then the token @Request.@Local.VarName~~ would resolve to "Standard".
Limitations
Nesting only works with Constant, Data, Local, Request, and Shared tokens, and only one level of nested tokens will be resolved, so this won't work:
NO: @Request.@Local.@Local.VarName~~~
You may find that it's possible to nest the token type as well and even insert literal text into the token and make it work, but those combinations are not supported officially and may break from one Info version to the next - proceed down that path at your own risk.