Pass Arguments through ViewRedirector

[blurblebot]

Is it possible to pass a replacementMap argument through a viewRedirector link?

If that's a mangled question, what I mean is that I'd like to have the redirect button on one of my panels in an "inverted flow, panel-defined search" take me to another view and have the argument I've entered in the first view load into the search field of the view I'm clicking through to.

If that, too, is a mangled question, what I mean is that I'd like to have magic.

Thank you.

[sideview · Accepted solution]

its a good question. The short answer unfortunately is no.

but I can indeed demangle the question to give the long answer. 😃

'replacementMap' is an idiosyncracy of the ExtendedFieldSearch module. So it means you're using ExtendedFieldSearch, which isnt necessarily a bad thing.

Other newer modules like the so-called 'lister' modules use a two-step system where the form element module puts out an abstract key, sometimes called a 'setting', and sometimes called a 'context value', and then there's another module like ConvertToIntention downstream that converts that simple key value into an intention somehow.

ExtendedFieldSearch on the other hand does both of these things, and actually outputs no simple key at all. So ViewRedirector wouldnt even have the user's typed-in value anyway, even if it could pass a dynamic value. So that's problem #1.

There is a module that looks a lot like ExtendedFieldSearch, called TextSetting. TextSetting just outputs a simple key so it behaves like the others. Meaning you can leverage a ConvertToIntention module downstream and its the same way you would set up a form search config with StaticSelect, or SearchSelectLister, or even an inline drilldown config.

If you then look at the docs for ViewRedirector it does actually have a param "uriParam.*" meaning you can put <param name="uriParam.foo">17</param> into it, and the user will be taken to viewName?foo=17.

However this isnt really very useful because it does no dynamic $foo$ replacement meaning there's no way to do <param name="uriParam.foo">$mySettingFromMyTextSettingModule$</param> which is what you'd want....

Hopefully the latter will be fixed soon. In the discover app I patch a lot of modules pretty significantly to fix incomplete implementations like this, and at some point im going to try and release a little toolkit of such patches.

[sideview]

check out the app on splunkbase "UI Examples for 4.1" if you havent already (NOT the older "UI Examples" app.) It has 50 or 60 example views and embedded copy and it does a sort of walkthrough through the key parts of the advanced XML.

[blurblebot]

Not only have you answered the question I've asked, but you've answered the question I'd rather have asked, and now I know why I'd rather have asked it. Thanks!