Hi,
I'm trying to understand a bit better the behaviour of 'change' and 'condition' tags when specifically used within Text Input Forms.
I'm seeing some strange (to me at least) behaviour and want to understand if others had seen the same. Or if it's possibly a bug of some sort.
To demonstrate the problem, I've just put together a simple Form:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="tok_text_1" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="tok_text_1">CHANGED</set>
</condition>
<condition>
<set token="tok_text_2">$tok_text_1$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$</title>
</panel>
</row>
</form>
I've got a couple of expectations of what should happen here when I enter text into the Input:
If I enter anything other than 'bug', both tokens should be set to the text I've entered:
If I enter 'bug' , then $tok_text_1$ should be changed to 'CHANGED'. $tok_text_2$ should remain either unset or with it's previous value
Now if I run though some scenarios of what actually happens...
Load the Form, which has the URL: http://127.0.0.1:8000/en-GB/app/search/input_change_test
This results in a title of: Token 1: test | Token 2: $tok_text_1$
This results in a title of: Token 1: test2 | Token 2: test
So what's happening here?
- In step 1, it would appear that the second change condition isn't being applied to set $tok_text_2$
- In step 2, it would appear that the second change block IS being applied, but based on the PREVIOUS value of $tok_text_1$
Now let's take a new scenario. Again, reload the dashboard with the URL from above (I.e. Remove and lingering $form.xxx$ tokens from the string).
This results in a title of: Token 1: bug | Token 2: $tok_text_1$
This results in a title of: Token 1: bug2 | Token 2: bug
So what's happening here:
- In step 1 , it would appear that the first change condition isn't being applied to alter $tok_text_1$ to 'CHANGED'
- In step 2, it would appear that the second change block IS being applied, but based on the PREVIOUS value of $tok_text_1$
Both are very similar. But here's another little twist...
If you load the URL as: http://127.0.0.1:8000/en-GB/app/search/input_change_test?form.tok_text_1=bug
This results in a title of: Token 1: CHANGED | Token 2: $tok_text_2$
Now to my question.
Can anyone help me understand what's happening here?
- I'm interested in knowing if this is expected behaviour?
- What's the 'flow' around how these change conditions get evaluated?
The closest explanation I can come up with is from the Token Usage in Dashboard section of the manuals.
This suggests that 'value' isn't a available token in 'text' inputs, therefore can't be used in change conditions. 'label' and 'value' are only available in:
If that's the case, then how can you reference the text that's been entered into the text input?
Thanks in advance,
Graham.
There's something about the token set by its input and using it inside these change statements that doesn't exactly work as you expect. I can't point you to any documentation, this is from personal experience and testing and it may change in the future, but I've found that you can't use the token inside these statements because they're not yet set to anything when the js code handling the value change runs. However, you can use the (temporary) token $value$
inside these change
statements, as they contain the value the user just selected (there's also a $label$
token available if applicable, e.g. on dropdowns, not in the case of your text input).
Now this is where things become tricky because the behavior is possibly undefined. I don't know if you're intended to set the token of your input in a change
statement, and I've always avoided that by using my own tokens with set
(using value
as above yields the same result, but consistently). First, if I change your token use to $value$
, I get this:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="tok_text_1" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="tok_text_1">CHANGED</set>
</condition>
<condition>
<set token="tok_text_2">$value$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
</panel>
</row>
</form>
This sets tok_text_2
entirely as expected (if you enter "bug", the value stays what it was before because the condition never reaches the default/last option). tok_text_1
on the other hand is what the input sets it to (so it says "bug" and not "CHANGED"), probably because that runs after the conditionally set
tokens are evaluated. However, and this looks inconsistent to me, if you enter "bug" into the text input, click on "Edit" and change the source in a way not relevant to the tokens (e.g. add a space to the panel title) and save that, you end up with "CHANGED" as the value for tok_text_1
.
In conclusion, I'd advise you to use independent tokens when set
ting them directly in a change
statement, like so:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="unused" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="tok_text_1">CHANGED</set>
</condition>
<condition>
<set token"tok_text_1">$value$</set>
<set token="tok_text_2">$value$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
</panel>
</row>
</form>
This should give you the expected behavior.
PS: if you want to change the input as well, use form.tokenName
. Try this out to see what I mean:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="tok_text_1" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="form.tok_text_1">CHANGED</set>
</condition>
<condition>
<set token="tok_text_2">$value$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
</panel>
</row>
</form>
Feel free to ask any remaining questions!
gvmorley, thank you for taking the time to explain this frustrating situation, as I was just about to create a post and call "bug" on this bizarre token behavior myself. This thread helped me a lot!
There's something about the token set by its input and using it inside these change statements that doesn't exactly work as you expect. I can't point you to any documentation, this is from personal experience and testing and it may change in the future, but I've found that you can't use the token inside these statements because they're not yet set to anything when the js code handling the value change runs. However, you can use the (temporary) token $value$
inside these change
statements, as they contain the value the user just selected (there's also a $label$
token available if applicable, e.g. on dropdowns, not in the case of your text input).
Now this is where things become tricky because the behavior is possibly undefined. I don't know if you're intended to set the token of your input in a change
statement, and I've always avoided that by using my own tokens with set
(using value
as above yields the same result, but consistently). First, if I change your token use to $value$
, I get this:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="tok_text_1" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="tok_text_1">CHANGED</set>
</condition>
<condition>
<set token="tok_text_2">$value$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
</panel>
</row>
</form>
This sets tok_text_2
entirely as expected (if you enter "bug", the value stays what it was before because the condition never reaches the default/last option). tok_text_1
on the other hand is what the input sets it to (so it says "bug" and not "CHANGED"), probably because that runs after the conditionally set
tokens are evaluated. However, and this looks inconsistent to me, if you enter "bug" into the text input, click on "Edit" and change the source in a way not relevant to the tokens (e.g. add a space to the panel title) and save that, you end up with "CHANGED" as the value for tok_text_1
.
In conclusion, I'd advise you to use independent tokens when set
ting them directly in a change
statement, like so:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="unused" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="tok_text_1">CHANGED</set>
</condition>
<condition>
<set token"tok_text_1">$value$</set>
<set token="tok_text_2">$value$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
</panel>
</row>
</form>
This should give you the expected behavior.
PS: if you want to change the input as well, use form.tokenName
. Try this out to see what I mean:
<form hideEdit="false">
<label>Input Text Test</label>
<fieldset autoRun="true" submitButton="false">
<input type="text" token="tok_text_1" searchWhenChanged="true">
<label>Enter any text</label>
<change>
<condition value="bug">
<set token="form.tok_text_1">CHANGED</set>
</condition>
<condition>
<set token="tok_text_2">$value$</set>
</condition>
</change>
</input>
</fieldset>
<row>
<panel>
<title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
</panel>
</row>
</form>
Feel free to ask any remaining questions!
Jeffland, you area awesome! Thank you so much for your explanation! I was having the exact same issue where my fields were showing the previous token value (as opposed to the current), and your trick using $value$
worked perfectly! I too was unable to find any documentation addressing this behavior.
@abulco01, predefined input tokens $value$
and $label$
have definitely been covered in Splunk Documentation: http://docs.splunk.com/Documentation/Splunk/latest/Viz/tokens#Predefined_tokens_for_accessing_labels...
Also Splunk Dashboard Examples also covers Input Label and Value example.
There are several examples on Splunk Answers around using value
or $value$
to access Text Box Value depending on where they are being accessed within the text box <change>
event handler.
does this also work with multiselect ?
No, multiselects do not have a change event handler. Docs here.
@Nam7Splnk @jeffland, there is a limitation with checkbox and multiselect input <change>
event handler, however, we can use our own JavaScript to handle and retrieve multiple values selected. Refer to one of my recent answers for the same: https://answers.splunk.com/answers/504338/using-eventhandler-with-multiselectinput.html
thanks @niketnilay, @jeffland. your responses are very helpful.
The form.token
was the part I was missing. Without it I wasn't getting the token overridden when I was trying to modify a second text token. Thanks.
Hi Jeffland,
My Scenario:-
If host=AB* then need to get the data from macro $Host$_Base_Search
,( host=C* OR host != AB*) then need to get the data from different macro $Host$_Base_Search
.
US
AD
if host=AB* then macro US_Base_Search
host=C* then macro AD_Base_Search
Please help me.
Thanks in advance..
I don't see how this is related to the question discussed above. I would suggest you ask a new question.
Sorry for the confusion. i'll post a new question.
Hi,
Many thanks for the detailed reply.
It's reassuring the see that you also saw the same inconsistency when trying the re-set the same token in the change
block that was used for the input.
Maybe it's by design? If any of the Splunk folks are reading, if it is, perhaps a little update in the change
& condition
docs to just highlight this?
Your approach makes a lot of sense. Essentially, just have a 'disposable' or 'temporary' token for the the input (in your example token="unused"
). Then just set new tokens based on the value contained within it.
I like it - a really good approach.
Thanks for taking the time to put together your response.
Graham.
Glad I could help 🙂
I've had good experience giving feedback directly on the relevant documentataion sites, at the botton where it says "Was this topic useful". The folks receiving that feedback are really helpful and competent and take care to look into the issues brought up to them, escalating to the appropriate people if needed or just downright correcting/enhancing the docs.