An architecture for adhoc views

[rashidkpc]

I'm creating this ticket for the sake of discussion.

Kibana currently has no way of generating adhoc views. This makes the following tickets challenging to implement cleanly:
#180
#402
#168

I'm not looking for solutions for specifying a query, thats simple but inflexible. I'm looking for ideas around generating dashboards schemas on the fly.

[spalger]

What about allowing dashboard config files to be javascript files that pass an object to window.loadConfig? We could probably include them as a service even, if users need to be able to specify custom filters/queries programmatically?

[rashidkpc]

so there's already a dashboard.dash_load that can take a dashboard and load it.

https://github.com/elasticsearch/kibana/blob/master/js/services.js#L667-L695

Should we expose that via the URL? Should you be able to pass in the entire dashboard schema via the URL?

What about parameterized views? Eg, a precomposed view that just needs a few bits of information filled in, how can we do that cleanly? Could we have some special tag you could stick in the dashboard file that would get replaced with url parameters? Should we do a hash of parameters or just do it by position in the route?

[spalger]

I think that building the entire dashboard via the URL could easily be supported if that's how users want to do it, why not? I don't think it's very clean, and I wouldn't want to implement my dashboards that way but it's downright simple.

I thought about some sort of mapping from panel to query string, allowing users to specify in the panel config that the "username" param sets the "querySrv.list[0].query" property, but then I figured it'd be simpler to just abstract away the core properties and write a little DSL for dynamically setting the config.

I think we could go as far as parsing the query string for the users, and providing it to the dynamic config file, maybe even make it simpler for them to find the query they are interested in (via some sort of unique name/id setting), and allow them to display messages like "you need to specify a username" and such.

We would see the .js in the config file name (eg. "#/dashboard/dashboards/user_records.js") execute it as js within our little sandbox and they could write things like this:

// extend an existing config file, could load from file system, or they could build it from scratch.
get_es_config('user_records')
.then(function (config) {
  var user_query;
  if (args.username) {
    user_query = config.getPanel('username_query').addQuery();
    user_query.query = 'username:'+args.username;
    user_query.pinned = true;
    config.getPanel('timeselector').timespan = '1w' || args.timespan;
  } else {
    throw new Error('You must specify a username parameter in the querystring');
  }

  loadConfig(config);
})

[rashidkpc]

Just pushed the first iteration of this concept here:
https://github.com/rashidkpc/kibana3/tree/templated_json

This allows for 2 ways of building dashboards. Templated JSON, and fully custom Javascript dashboard object creation.

The first method, templated JSON uses mustache style variable interpolation, eg {{query}}. For example, a snippet from logstash.json might look something like:

"0": {
  "query": "{{ARGS.query || '*'}}",
  "alias": "",
  "color": "#7EB26D",
  "id": 0
}

The value of the query could then be passed to the dashboard using this url:

http://localhost:8000/index.html#/dashboard/file/logstash.json?query=extension:html

A full example of this can be found at:
https://github.com/elasticsearch/kibana/blob/master/src/app/dashboards/logstash.json

The second method is completely custom dashboard objects built from javascript. This allows you to build complex logic into your dashboard creation, for example adding or removing panels based on URL parameters. The script must build a valid dashboard object, and return it. You can add something like logstash.js to the dashboards directory and access it via:

http://localhost:8000/index.html#/dashboard/script/logstash.js?query=extension:html,extension:css 

A full example of this approach, with comments is in:
https://github.com/elasticsearch/kibana/blob/master/src/app/dashboards/logstash.js

In both cases, all URL parameters are accessible via the ARGS object. Eg, in the example urls above, query would be accessible via ARGS.query

[camerondavison]

Does this work with gists?