how to display error message if value edited and search in URL splunk sideview

[disha]

I am using URLLoader module with sideview modules in my view 1 . When user clicks on any row of table it goes to next view 2 with value $customerid$ .
the addressbar in view 2 is like /app/myApp/ACustomerView?CustomerID=1016
Just to cleanup all the accidential error if user edit the url like
/app/myApp/ACustomerView?CustomerID=102939383
this customerid is not exist in my data. so I need to popup an error message that "Id not exist".
or may be it can go to new view3 /app/myApp/NonExistId?CustomerID=102939383
and I could display the message "customer ID 102939383 does not exist.
Any thoughts??
Thanks in Advance.

[sideview]

Well, as with many slightly weird use cases, you can get surprisingly far just with PostProcess, ResultsValueSetter and Switcher.

Let's take a very simple starting point, where we have a TextField module into which the user can type a sourcetype:

<module name="TextField" layoutPanel="mainSearchControls" autoRun="True">
  <param name="name">sourcetype</param>
  <param name="label">Sourcetype</param>
  <param name="template">$name$="$value$"</param>

  <module name="Search">
    <param name="search">* $sourcetype$</param>

    <module name="Pager">
      <module name="Table"/>
    </module>
  </module>
</module>

I've put in some extra carriage returns just so you can more clearly make out the modules at work in this simple example. When the user types in their sourcetype term, a search gets kicked off for that sourcetype term, and then the Table module will render with rows from that search, and the Pager module tells the Table to only render one page at a time.

We can take this simple example and add in some strange looking configuration. Now it looks like this:

<module name="TextField" layoutPanel="mainSearchControls" autoRun="True">
  <param name="name">sourcetype</param>
  <param name="label">Sourcetype</param>
  <param name="template">$name$="$value$"</param>

  <module name="Search">
    <param name="search">* $sourcetype$</param>

    <!-- we sneak in a strange looking piece of config that uses PostProcess,
    ResultsValueSetter and Switcher to display a message when there are no 
    results -->
    <module name="PostProcess">
      <param name="search">| stats distinct_count(sourcetype) as numberOfSourcetypes</param>

      <module name="ResultsValueSetter">
        <param name="fields">numberOfSourcetypes</param>
        <module name="Switcher" group=" ">
          <param name="selectedGroup">$numberOfSourcetypes$</param>
          <module name="HTML" group="0">
            <param name="html"><![CDATA[
              <div class="warn">
                Sorry there are no events for the given sourcetype of "$sourcetype.rawValue$"
              </div>
            ]]></param>
          </module>
        </module>
      </module>
    </module>

    <module name="Pager">
      <module name="Table"/>
    </module>
  </module>
</module>

Now every time a new value comes down through this config and hits the new config we added in, The ResultsValueSetter will go and get a value from the server, call it $numberOfSourcetypes$, and that value will be the distinct_count of sourcetypes, in the search that was kicked off for the Table. then the Switcher module uses that value retrieved by the ResultsValueSetter, and if the value is "0", then it shows the HTML module with our little message. If the value is anything other than "0", the HTML module is hidden.

The drawbacks with this cute little example:

1) As the page is loading the error message is actually visible for a moment and this is pretty confusing to the end-user. I can probably make an improvement or add a param to the Switcher to improve that in a future version.

2) When you get the error message to show up, and then you submit the form again with corrected input, there's a little delay of about a second before the message goes away. This is a bit confusing too. This delay is just due to the fact that the Switcher has to wait for hte search to dispatch, and for the ResultsValueSetter's postProcess request to come back from the server. When I revisit #1, I'll think about whether I can improve this behavior too.