Can I use a token in the value of an input?

[jeffland]

Hi. I have a dashboard with a panel on top that displays some data, grouped by a selected field (selected through an input). Below that panel, there is another panel which displays a chart containing the aggregated values from the data in the top panel.
In that second panel, I would like to be able to give the user an option to show additional data, to see how the aggregated values compare relative to something. For that, I have another input to select between absolute and relative display of the data. Since the relative aspect is dependent of the field selected in the upper panel, I'd like to use the token from above in the value.
In case this sounds too complicated, here is some xml to demonstrate:

<!--first row-->
<row>
  <panel>
    <input type="dropdown" token="token_a" searchWhenChanged="true">
      <choice value="foo">foo</choice>
      <choice value="foo_max">foo_max</choice>
      ...
      <table>
        ...
<!--second row-->
<row>
  <panel>
    <input type="dropdown" token="token_b" searchWhenChanged="true">
      <choice value="| stats count by bucket">Absolute</choice>
      <choice value="| stats count by bucket | join bucket [search host=bar | bucket $token_a$ as bucket ...]">Relative</choice>
      ...
        <table>
          <search>
            <query>some_searching $token_b$

I hope this explains what I want to do. The problem is that apparently, you can't use a token in the value of an input (the second choice of the second row), as this will be translated literally and thus result in a search that contains the command "| bucket $token_b$ as bucket".
I have tried replacing the dollars with double dollars and escaping the dollars with a backslash, which both didn't work (the token is replaced literally, so the search is then "| bucket $$token_b$$ as bucket" or "| bucket \$token_b\$ as bucket"). I also tried placing the value of the input in CDATA brackets, which only breaks the xml.

So how do I do this? Is this possible at all? I know I could split up token_b to multiple parts, create them with a couple of change - condition - set lines and fiddle everything back together in the search of the second row, but that is error prone and hard to maintain.

Any input appreciated!

[yuanliu]

I disagree with the other answer. I have always used values from preceding inputs in search terms for the rest of inputs, e.g.,

    <input type="dropdown" token="source_tok" searchWhenChanged="true">
      <label>Source</label>
      <fieldForLabel>source</fieldForLabel>
      <fieldForValue>source</fieldForValue>
      <search>
        <query>index=main
| stats count by source</query>
        <earliest>-1d@h</earliest>
        <latest>now</latest>
      </search>
    </input>
    <input type="dropdown" token="host_tok" searchWhenChanged="true">
      <label>Host</label>
      <fieldForLabel>host</fieldForLabel>
      <fieldForValue>host</fieldForValue>
      <search>
        <query>index=main source=$source_tok$
       | stats count by host</query>
        <earliest>-1d@h</earliest>
        <latest>now</latest>
      </search>
    </input>

[rjthibod]

You are missing the use case in the original question. The issue is not the use of tokens in the search element of an input - something I do all the time as well. The issue is the use of the token in the choice element of the input, because the choice elements actual value is only interpreted once. This does not work as the questioner wants. Neither does it work in prefix, suffix, valueSuffix, or valuePrefix elements.

[rjthibod · Accepted solution]

The answer is no, you can't or shouldn't use a token in the value definition of another token. It will not update the way you want.

Instead, you have to usually build different displays for the variations you want and toggle the visible displays, or you have to build the flexibility into the query string such that it is split up into parts and more flexible to the variations you want.

You have not shared all of your XML, so I can't give you a working option. Still, the answer is you can't do what you want so you have to build one of the variations I described.