I used the following example from the Splunk Documentation to use tokens in my Web Framework Dashboard.
{% dropdown id="selIndex" value="$indexName$"|token_safe %}
{% searchmanager id="mySearch" search="index=$indexName$"|token_safe %}
An issue I ran into was, What if I want to show "All" of an item, even if it is blank.
I found that putting in * as a default value was not good as it did not include them if the field did not exist in the data, as this data is dynamic.
I have 10+ filters on this dashboard and hardly any results were being returned because of the * filtering out all the blank or null values.
My Workaround was to set the token values myself through Javascript and set them to something similar to "indexName=\"" + ..getInstance("sel-index").val() + "\""; and changing the search to be search="$indexName$"|token_safe
I would also check to see if the dropdown field was set to a value of blank and set the token to blank otherwise.
Has anyone else run into this issue or know a proper way of using the tokens and retrieving all records whether or not they are blank or not? (without using fillnull as it gives a huge performance hit)
The solution you've put together sounds good, given the current constraints of the system.
It's true that there is a small difference between having a "index=*" clause and having no clause. Namely the former requires the field to at least be present whereas the latter does not.
The current token binding support only allows token values to be computed based on string substitutions into fixed templates. If there was a way to have tokens computed based on arbitrary computations, you could have something like:
splunkjs.mvc.Components.get('default').set('indexClause', function() {
return (dropdown.val() === undefined) ? '' : ('indexName="' + dropdown.val() + '"');
}, {computed: true}); // HYPOTHETICAL
However the preceding syntax would still require you to write custom code to define the computation.
The ability to compute tokens based on custom code is something that the framework team has thought about, but it is not implemented at this time.
Great - David is the smart one, so glad he could answer your question 🙂
I do this in order to get all values of that item whether or not it is existent or not, this allows for more lean logs as you do not include fields that do not have data.
dfoster answered it pretty well. Overall it has to do with dropdowns/text inputs etc and the ability to filter on "null" or non-existant fields when you set token values through the web framework. basically all fields that you filter by must be present in the data in order to use the out of the box value="$token$", instead of setting it there I go through javascript and set the token to the following: MyItem="ValueOfToken"
So
tokens.set("token", "MyItem=\"ValueOfToken\"");
@aelliott - I'm not sure I'm following the issue. Could you give a concrete example? I just want to make sure we can answer the right question.
The solution you've put together sounds good, given the current constraints of the system.
It's true that there is a small difference between having a "index=*" clause and having no clause. Namely the former requires the field to at least be present whereas the latter does not.
The current token binding support only allows token values to be computed based on string substitutions into fixed templates. If there was a way to have tokens computed based on arbitrary computations, you could have something like:
splunkjs.mvc.Components.get('default').set('indexClause', function() {
return (dropdown.val() === undefined) ? '' : ('indexName="' + dropdown.val() + '"');
}, {computed: true}); // HYPOTHETICAL
However the preceding syntax would still require you to write custom code to define the computation.
The ability to compute tokens based on custom code is something that the framework team has thought about, but it is not implemented at this time.