Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add registry for doc table details #6105

Merged
merged 7 commits into from
Feb 5, 2016
Merged

Add registry for doc table details #6105

merged 7 commits into from
Feb 5, 2016

Conversation

trevan
Copy link
Contributor

@trevan trevan commented Feb 4, 2016

This PR creates a registry for doc table details. It moves the table and json viewer into the registry. You can control whether a viewer should be shown for a specific hit.

It uses the render_directive but I couldn't figure out how to pass scope variables into it so I modified the directive and added a "scope" attribute. If there is a better way, I'll change it.

I'm working on the tests but wanted to get the pull request submitted for feedback.

This partially closes #5214

@elasticsearch-release
Copy link

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then say 'jenkins, test it'.

…gistry

Conflicts:
	src/plugins/kibana/index.js
	src/ui/ui_exports.js
@jimmyjones2
Copy link
Contributor

Just what I need, big +1, thanks!

@spalger
Copy link
Contributor

spalger commented Feb 4, 2016

This is awesome, excited to review

@spalger spalger self-assigned this Feb 4, 2016
@@ -6,7 +6,8 @@ module.directive('renderDirective', function () {
return {
restrict: 'E',
scope: {
'definition': '='
'definition': '=',
'scope': '=?'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😔 not sure how we can make this better but I hope we can come up with something. Referring to $scope.scope internally is gross.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the definition included a scope definition? We would have to implement that in render_directive, but that sounds like fun to me.

definition = {
  controller...
  controllerAs...
  scope: {
    hit: '=',
    indexPattern: '=',
    onSave: '&'
  }
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a stab at this in #6115, mind trying it out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried it out. It works but feels a little awkward. I have to define the attributes in both the definition and in the render-directive html.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the pull request and you can see how I used it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I understand how that might be a bit awkward but I see it as documenting what you pass in and what you expect to be passed in.

People can use the `<render-directive>` directive to programatically extend views, but passing values to those views is not as easy. To make it easier we will support defining scope bindings just like directives support, and those bindings will be applied to the isolate scope created for the rendered directive.

The `<render-directive>` the majority of angular 1.4s syntax. The differences include:
 1. `=?` is not implemented
 1. Isolate scopes are always created, even is `scope:` is not defined
@@ -22,7 +22,8 @@ module.exports = function (kibana) {
'spyModes',
'fieldFormats',
'navbarExtensions',
'settingsSections'
'settingsSections',
'docTableDetailViews'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this as an extension point for plugins, but I think the existing doc viewers should use it (rather than being included directly). Perhaps they should get their own plugin, similar to the kbn_vislib_vis_types plugin.

Since there isn't any direct dependence on the docTable It may make sense to go generic with this export type and just call it docViews, then the docViewer (or any other component that wants to display docs) can utilize them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created kbn_doc_views plugin and moved them there. The registry is now named docViews.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💃

@spalger
Copy link
Contributor

spalger commented Feb 4, 2016

jenkins, test it

Trevan Richins added 4 commits February 4, 2016 10:48
Use the new render-directive attr mechanism.
Rename the registry to be more generic
Create default values
Add a name field in case the title has quotes or other characters
Update import code style
@trevan
Copy link
Contributor Author

trevan commented Feb 4, 2016

@spalger, I think I've resolved your comments. I also fixed up the tests so they should pass now.

@epixa
Copy link
Contributor

epixa commented Feb 4, 2016

jenkins, test it

@trevan
Copy link
Contributor Author

trevan commented Feb 4, 2016

@epixa, I don't understand why the build failed. It has the message:

/home/jenkins/workspace/kibana_core_pr/ephemeral-x-f5309ec.sh: line 2: syntax error near unexpected token newline' /home/jenkins/workspace/kibana_core_pr/ephemeral-x-f5309ec.sh: line 2:'

Any ideas?

@epixa
Copy link
Contributor

epixa commented Feb 4, 2016

Hmmm... I actually have no idea off-hand, but it certainly doesn't seem like anything that has to do with your PR.

@epixa
Copy link
Contributor

epixa commented Feb 4, 2016

jenkins, test it

@epixa
Copy link
Contributor

epixa commented Feb 4, 2016

That one seemed to work. ¯_(ツ)_/¯

@trevan
Copy link
Contributor Author

trevan commented Feb 5, 2016

@spalger, @epixa what is left for me to do?

@spalger
Copy link
Contributor

spalger commented Feb 5, 2016

Haha, nothing!

spalger added a commit that referenced this pull request Feb 5, 2016
@spalger spalger merged commit 0b122eb into elastic:master Feb 5, 2016
@spalger
Copy link
Contributor

spalger commented Feb 5, 2016

Very nice @trevan!

@spalger
Copy link
Contributor

spalger commented Feb 5, 2016

giphy 2

@trevan trevan deleted the doc-detail-views-registry branch February 5, 2016 22:10
@trevan
Copy link
Contributor Author

trevan commented Feb 5, 2016

@spalger, thanks

@epixa
Copy link
Contributor

epixa commented Feb 5, 2016

@spalger Can you think of any reason why this couldn't go into 4.5?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Formatting plugins for JSON results
5 participants