Closed Bug 980555 Opened 6 years ago Closed 2 years ago

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

Categories

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

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: irakli, Unassigned)

References

Details

Attachments

(1 file, 7 obsolete files)

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.
Summary: Bug 980553 - API for defining Custom output handlers (a.k.a printers) → API for defining Custom output handlers (a.k.a printers)
Priority: -- → P1
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
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.
Attached file Object Inspectors.md (obsolete) —
Here's the JEP, added as an attachment. For now, at least, I'm calling these "Object Inspectors".
Attachment #8433490 - Flags: feedback?(zer0)
Attachment #8433490 - Flags: feedback?(rcampbell)
Attachment #8433490 - Flags: feedback?(rFobic)
Attachment #8433490 - Flags: feedback?(jsantell)
Attachment #8433490 - Flags: feedback?(jgriffiths)
Attachment #8433490 - Flags: feedback?(evold)
Attachment #8433490 - Flags: feedback?(dcamp)
Comment on attachment 8433490 [details]
Object Inspectors.md

Pointed out my concerns in the pull request.
Attachment #8433490 - Flags: feedback?(rFobic) → feedback-
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.
Attachment #8433490 - Flags: feedback?(jgriffiths) → feedback+
whoa, can we put this on github please please please?
I feel like this is violating the JEP workflow being in bugzilla. :)

happy to leave feedback there.
er, where "there" is github.
Comment on attachment 8433490 [details]
Object Inspectors.md

canceling feedback request. See github PR for feedback.
Attachment #8433490 - Flags: feedback?(rcampbell)
I think a lot of these changed after meeting in Portland, is this PR still up to date?
Flags: needinfo?(cbrem)
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).
Attachment #8433490 - Attachment is obsolete: true
Attachment #8434328 - Attachment is obsolete: true
Attachment #8433490 - Flags: feedback?(zer0)
Attachment #8433490 - Flags: feedback?(jsantell)
Attachment #8433490 - Flags: feedback?(evold)
Attachment #8433490 - Flags: feedback?(dcamp)
Flags: needinfo?(cbrem)
Attached patch bug980555_sdk_v0.patch (obsolete) — Splinter Review
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.
Attachment #8438953 - Attachment is obsolete: true
Attachment #8443710 - Flags: feedback?(jsantell)
Attached patch bug980555_devtools_v0.patch (obsolete) — Splinter Review
Here's the devtools component to go with the SDK component mentioned in the previous comment.
Attachment #8443711 - Flags: feedback?(jsantell)
Attached patch bug980555_devtools_v1.patch (obsolete) — Splinter Review
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.
Attachment #8443710 - Attachment is obsolete: true
Attachment #8443711 - Attachment is obsolete: true
Attachment #8443710 - Flags: feedback?(jsantell)
Attachment #8443711 - Flags: feedback?(jsantell)
Attachment #8447453 - Flags: feedback?(rFobic)
Attachment #8447453 - Flags: feedback?(odvarko)
Attachment #8447453 - Flags: feedback?(jsantell)
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.
Attachment #8447453 - Flags: feedback?(rFobic) → feedback-
Attached patch 980555.patch (obsolete) — Splinter Review
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
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.
Attachment #8447453 - Attachment is obsolete: true
Attachment #8472021 - Attachment is obsolete: true
Attachment #8447453 - Flags: feedback?(jsantell)
Attachment #8477073 - Flags: feedback?(jsantell)
Attachment #8477073 - Flags: feedback?(jsantell)
Priority: P1 → --
https://bugzilla.mozilla.org/show_bug.cgi?id=1399562
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.