Inline drilldown from HTML Module

[chris]

Ist it possible to make an inline drilldown from an HTML module (using a div/link ..) instead of using a SimpleResultsTable or a Table Module?

The HTML Module is used to emulate single values. When a user clicks on one of the values I would like to have the same behaviour as the "drilldown1_tables" in Sideview Utils (Version 2.3).

<module name="HTML">
    <param name="html">
        <![CDATA[

        <h2>Failed Action X:</h2>

        <div class="valueDisplay"><div class="inner"><b>$results[0].count$</b></div></div>

        <h2>Failed Action Y:</h2>

        <div class="valueDisplay"><div class="inner"><b>$results[1].count$</b></div></div>


     ]]></param>
     <module name="Downstream visualization"></module>
</module>

[jpass]

Even though this question has an accepted answer I wanted to add something similar that I did and which might help others. It's not exactly the same but close.

1. I render a set of results in the Table Module
2. Use the 'Custom Embedding' feature of the Table Module to render an HTML module within each row of the table.
3. Hide all the fields you don't need to dispay in this table so all I have is a single value displaying in the HTML Module which is repeated for each result of the seach.
4. Problem: This won't allow a drill down unless you're ok having all your down stream modules stuck in the row cell. For example, if you want to display downstream modules in another panel, you can't unless you use the Gate Module.
5. Next place a Button Module under the embedded HTML Module
6. Next place a Gate Module under the Button Module
7. Next set the 'to' value of the Gate Module to 'some_id_value'
8. Next add another Gate module somewhere outside of your embedded Modules
9. Set the 'id' for this Gate Module to 'some_id_value'
10. The button drills down to the Gate which sends values laterally to the #2 Gate which is sitting theire waiting for a token. When it gets the token, it renders the modules downsream as if they were sitting downstream of the embedded modules.

[jpass]

No problem. I am having an issue in SideView Utils V. 2.6.3 where I can't drill down passed the second pager of results. I'll post a question to SPlunkBase for that soon.

[chris]

Thanks for posting this.

[sideview · Accepted solution]

We've chatted by email but I figured I should post a public answer here.

CustomBehavior

You could do this with a customBehavior and some ingenuity. It may seem like a simple thing perhaps, but it actually would be quite a complex customBehavior.

If you think about it, drilldown config on an HTML module will mean giving the HTML module children, but if you try it and see you'll see that those children are always visible. To change that and to implement an idea of a "selected" state, and the ability to pass that state downstream, your customBehavior would have to do the following:

1. HTML module doesn't maintain any selected state. so the customBehavior would have to maintain that. Probably adding a click handler to the container, examining $(evt).target to determine if it was one of the drilldown elements that were clicked, and then saving the identifier as the 'selection'. Then it would have to call pushContextToChildren.
2. an implementation of getModifiedContext that looks at that preserved selection and sets into the context before returning it. (This is how all downstream changes effected by modules are made.)
3. on initialize the module would have to hide all of its downstream modules.
4. on onContextChange it should hide all its downstream modules again
5. it would need an implementation of isReadyForContextPush, which is a seldom used framework method. The method would return false if there was no selected link property, true otherwise. This is what would prevent pushes from just blithely going on past the HTML module on their way downstream, before the user had clicked any of the elements.
6. If you wished different behavior than #4, then you'd have to override renderResults or onResultsRendered so as to paint the selection state back onto the rendered HTML.

All in all, it's a really long way to go for something that can be
accomplished a lot easier using an actual Table, or a Tabs module
(the label property of a dynamic tab can itself be dynamic so it could
have field values in it).

do cool magic with hash anchor links

For this you have to accept that some of the searches will probably reload when the link sare clicked. The page wont reload but, er, parts of it will.

1. Have a URLLoader on the page, have the clickable elements be "#" anchors like so:

<a href="#someKey=someValue">link 1</a> vs <a href="#someKey=someOtherValue">link 2</a>

1. When one of those two links is clicked, it'll change the page URL, which URLLoader will notice, and downstream from its location in the XML, it will push those keys. So $someKey$ will evaluate to either "someValue" or "someOtherValue". It's definitely a bit of a hack, and depending on what's downstream from your URLLoader you might redispatch all your searches.

Sideview builds it in as core functionality on the HTML module

Now coming at this from a different angle, it's unlikely to be the last time that someone wants this kind of functionality so I'll certainly consider adding it to the HTML module. The least evil implementation I can think of so far is as follows:

• if HTML is going to contribute a key downstream, then by Sideview convention it needs a "name" param. Which will determine the $foo$ key that is to be used downstream (If you look carefully you'll see they all follow this convention).
• Then we could have some predefined classname that the admin could put on the clickable elements, perhaps class="drilldownElement".
• The HTML module could notice it has been given a name param, notice it has at least one drilldownElement, and then do pretty much all of the rest of 1-6 (above) automatically.

• for name of "foo", you'd have

  foo = the value, backslash-escaped as necessary for the search language
  foo.value = same
  foo.rawValue = the value, but not backslash-escaped.
  foo.element - a little known but consistent sideview convention to pass down
  an actual DOM element reference. Comes in handy sometimes for customBehaviors.

[sideview]

you can certainly drilldown from HTML module to another page very easily, just by making a link tag. There are docs and examples about all this in the docs page "Module Documentation > the HTML Module > Using HTML to replace the SingleValue module". Note that the commentary here is about using HTML module to do an INLINE drilldown, meaning the user stays on the same page.

[Jason]

At my client this week they're using HTML modules and custom JS instead of singlevalue modules, due to their lack of drilldown. Now they're getting to the point where they want to drill down further from the HTML modules, so +1 for the ability for HTML to drill down.

[chris]

Thank you Nick, I updated the question

[sideview]

Can I assume that by "inline drilldown", you mean that the link, when clicked, causes other module config downstream from the link, to dispatch searches and render charts and tables. If so then only a customBehavior could do it, and you might be better off using a Button and then customizing the CSS to make Button look like a simple link. Please add more details and I'll give the best advice I can.