customViewer API: Registry to enable extension developers to add CustomViewers

[couzteau]

This change adds a public API to EditorManager that enables extension developers to add custom viewers to Brackets following the same pattern as implemented by ImageViewer: When a file is opened EditorManager is consulted for available CustomViewers for the given file type. If available the custom viewer is used by EditorManager to display the file.

A custom viewer would have to implement the following:

• render(fullPath, $editorHolder)
  • @param {!string} fullPath Path to the image file
  • @param {!jQueryObject} $editorHolder The DOM element to append the view to.
• onRemove()
  signs off listeners and performs any required clean up when editor manager closes
  the custom viewer

To register with EditorManager registerCustomViewerProvider(langId, provider) needs to be called where
@param {!String} languageId, i.e. image, audio, ... to identify a language known to LanguageManager
@param {!Object} provider Custom view provider instance

[peterflynn]

Nit: this is inconsistent with the previous bullet. Maybe just "render()" and "onRemove()" (with no "function") for both?

And also remove the extra copy of render() on the line just above here.

[couzteau]

√

[peterflynn]

@couzteau I've added a few comments but I think this looks great overall!

[couzteau]

@peterflynn Thanks for the review

[RaymondLim]

Done reviewing and no more to add since @peterflynn already done a nice review and comments.

[couzteau]

back to reviewers. Thanks

[RaymondLim]

It is weird to require itself. I don't think we want this way to pass ImageViewer module. I was expecting that you create a constructor here and convert all functions to methods of the new object, then pass to register function call with a new instance of the new object.

[TomMalbran]

An alternative would be to just pass exports as the ImageViewer module, since the provider just needs some sort of object with 2 methods. Which means that we can just pass it a simple object instead of creating a function and its prototypes.

EditorManager.registerCustomViewer("image", exports);

or

EditorManager.registerCustomViewer("image", {
    render: function () { ... },
    onRemove: function () { ... }
});

[peterflynn]

Yeah, either of those seems fine. I'd lean toward the 2nd form since we use that pattern in a number of other modules (and it doesn't force you to export APIs that you don't actually want anyone other than registerCustomViewer() to call).

[couzteau]

Thanks guys, I'll go with Tom's suggestion.

[couzteau]

Back to reviewers. Thanks.

[RaymondLim]

Looks good! Merging.