An abstraction layer that enables the UI to make a common subset of search language modifications to any given search string, without having to store any language-parsing code on the client.
Modules in Splunk's UI pass intentions down the module tree hierarchy, and the modules can modify the searches by adding intentions as they pass the search down the tree. With intentions, modules can contribute to a search in an number of ways:
- They can change out the underlying "base search" string (the SearchBar, HiddenSearch, and HiddenSavedSearch modules do this).
- They can add, modify, or clear the intentions living on top of the "base search" (SearchSelectLister and all "form search" modules do this).
- They can add or modify time ranges (the TimeRangePicker, HiddenSearch, and HiddenSavedSearch modules do this).
For example, the
addterm intention can safely add either
foo=bar to a search, and it can specify wither the term should be added to the first search clause, or added after any renames,
rex clauses, and so on.
Once a series of intentions reaches a special type of module--a dispatching module--the intentions are composed into a search and that search is run in Splunk. Most results modules are dispatching modules--if a results module doesn't have any results from a search by the time it is invoked in a view, the results module compiles the intentions and runs the resulting search.
For more information
In the Developer Manual: