980555 - API for defining Custom output handlers (a.k.a printers)

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

API for add-ons, that can hook into as a middleware to provide
custom printers for the values. API will be in form of simple
HTML page that is posted a message with an object grip that
it needs to render representation for.

Custom printers can be enabled in console along with custom
input handlers, so that presentation of output will match
presentation of input.

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

Thoughts on Object Inspector rendering, both Simple and Custom views:

A Simple view would be clicking on an <Ember Object> for example, and displaying that in the OI, using the VariablesView widget already there. In this case, it'd be an input of the <Ember Object> and output of a new object that'll be placed in the VariablesView. So, maybe hiding underscore'd properties, or moving hidden props to a top level property for displaying. Tricky part of this is defining what happens when a value changes (it would have to propogate to original property).

A more complex view would be just an iframe where a developer can render anything they'd like. There's a Chrome Backbone Debugger addon[1] (image[2]) that displays events triggered on an object, and could display things like a promise viewer for promises, or events bound to an object. This requires more work for the SDK developer, but offers a lot of customization. I think for now we should focus on the SimpleView OI, and maybe in the future (or in this, if it's straight forward), offer the full iframe custom view.

[1] https://chrome.google.com/webstore/detail/backbone-debugger/bhljhndlimiafopmmhjlgfpnnchjjbhd?hl=en
[2] https://lh4.googleusercontent.com/jAjsL39TfrNCm0FzAf7LRrWA1buncFsgKg8Vj3Xw42TeYDqmweXGFf02aeM5O90_Wtt0EIBxUjw=s1280-h800-e365-rw

Comment 2

[Connor Brem [:cbrem] [@cbrem]]

I've created a Jetpack Enhancement Proposal related to this bug. The proposal outlines an API close to the "Simple view" suggested by jsantell, with notes about how to extend the API into something similar to the "complex view".
The proposal is available here: https://github.com/cbrem/addon-sdk/blob/JEP/Object%20Inspectors.md, and an Etherpad document for discussing it is here: https://etherpad.mozilla.org/6P2gZHE7ug.

Comment 3

[Connor Brem [:cbrem] [@cbrem]]

Attachment: Object Inspectors.md

Here's the JEP, added as an attachment. For now, at least, I'm calling these "Object Inspectors".

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Comment on attachment 8433490 [details]
Object Inspectors.md

Pointed out my concerns in the pull request.

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Comment on attachment 8433490 [details]
Object Inspectors.md

+1 on the approach here wrt to what the developers / users will see. I know Irakli has concerns about the implementation approach that need to be addressed, in particular these apis should be remote-able.

Comment 6

[Erik Vold [:erikvold] (please needinfo? me)]

whoa, can we put this on github please please please?

Comment 7

[Rob Campbell [:rc] (:robcee)]

I feel like this is violating the JEP workflow being in bugzilla. :)

happy to leave feedback there.

Comment 8

[Rob Campbell [:rc] (:robcee)]

er, where "there" is github.

Comment 9

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 8433490 [details]
Object Inspectors.md

canceling feedback request. See github PR for feedback.

Comment 10

[Connor Brem [:cbrem] [@cbrem]]

Attachment: Link to Github pull-request: https://github.com/mozilla/addon-sdk/pull/1502

Comment 11

[Jordan Santell [:jsantell] [@jsantell]]

I think a lot of these changed after meeting in Portland, is this PR still up to date?

Comment 12

[Jordan Santell [:jsantell] [@jsantell]]

Also, here's an example of gDevTools being included and called from the SDK:
https://github.com/Gozala/addon-sdk/blob/61dfe911d4e3f585e1f3dd68e5988118f18542b0/lib/dev/toolbox.js

Comment 13

[Connor Brem [:cbrem] [@cbrem]]

Attachment: Link to Github pull-request: https://github.com/mozilla/addon-sdk/pull/1502

Here's the updated version, which reflects our Portland meeting and some challenges that I faced while implementing a preliminary version of the module.

The most significant change is that the API is not promise-based instead of synchronous so that it is compatible with grip clients (which are asynchronous).

Comment 14

[Connor Brem [:cbrem] [@cbrem]]

Attachment: bug980555_sdk_v0.patch

I've made a prototype which allows SDK users to apply a map to objects caught by a filter before there are passed on to the Variables View.

This prototype is rough, and may not be the best way to allow modification of the Variables View (a module which gives users complete control over the look and feel of the View may be better). Nevertheless, here it is!

This prototype consists of an for an SDK module and some devtools components. The SDK component is attached.

Comment 15

[Connor Brem [:cbrem] [@cbrem]]

Attachment: bug980555_devtools_v0.patch

Here's the devtools component to go with the SDK component mentioned in the previous comment.

Comment 16

[Connor Brem [:cbrem] [@cbrem]]

Attachment: bug980555_devtools_v1.patch

Here's a significantly changed API for modifying the Variables View's behavior.
Compared to the API in the last patch, this one hides much less of the VariablesView functionality. Also, it's more extensible. The VariablesView and VariablesViewController are only two devtools components which can be modified with it.

The devtools component of the patch is attached.
Here's a PR for the SDK component (which include an example): https://github.com/mozilla/addon-sdk/pull/1527.

Comment 17

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Comment on attachment 8447453 [details] [diff] [review]
bug980555_devtools_v1.patch

I have provided my feedback on the API here: https://github.com/mozilla/addon-sdk/pull/1527#issuecomment-48244222
I don't think my feedback is required for the devtools implementation details.

Comment 18

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Commented on the pull request:
https://github.com/mozilla/addon-sdk/pull/1527#issuecomment-48244222

Honza

Comment 19

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: 980555.patch

Updated devtools side with more methods -- clearing the flags (which will need to happen on the sdk side for unloading so it can go back to how it was originally). Need to add some tests.

Other changes, getting rid of the enum for flags -- "webconsle" should be sufficient and self-declarative, without referencing modules from the SDK

Comment 20

[Connor Brem [:cbrem] [@cbrem]]

Attachment: bug980555_devtools_v3.patch

Added tests for devtools components.
I decided not to expose clearing flags on the SDK side yet. This seems like it would be most useful for allowing one addon to override another addon's flags...but presently this can't happen -- only the first addon to set flags has any effect.

Comment 21

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562