Orion/Visual Plugin Strategy
This page describes our current support for "visual plugins" in Orion and discusses where we need to go.
Browser as an IDE
For those coming to Orion from desktop IDE's, and in particular Eclipse, a common question is "can I extend Orion's UI similarly to what I do in Eclipse today?" The answer is that the extension model is similar in many ways, but the key conceptual difference to be understood is that the browser is the IDE.
Developers work with many tools in the context of doing their work: editors, bug tracking systems, source control, test tools, image and graphics tools, etc. Orion is not a visual container for all your IDE tooling. We consider the browser to be the visual container and in Orion we focus on identifying the tasks that are integral to web development and providing pages that support these tasks. Orion's plugin architecture and extension model allow developers to contribute new behavior to existing Orion pages and to link to pages from other sites.
Orion UI extensions vs. Eclipse extensions
Many of the UI extension points in Orion should look familiar to the Eclipse developer.
Views and Editors
Unlike Eclipse, Orion doesn't have extension points like "view" or "editor" wherein a plugin can open a visual rectangle inside Orion and display some content. Since the browser is the IDE, we expect a contribution of a view or new kind of editor to be made by building a page. That page is linked to Orion via our various command or link extension points. Perhaps some day we will support "show view" and open a box on our page, but this is not where we wanted to start. Given our bias toward the Eclipse IDE, we want to push the envelope on task-oriented pages, and understanding the implications on the user.
Working with the editor should feel quite familiar to someone who has extended the eclipse editor. We have editor extension points that are quite similar to those in Eclipse, such as content assist, editor line annotations, custom outliners, etc. The API's are structured differently given we are communicating across an iframe to a plugin hosted on another site, but the spirit is quite similar.
Contributing commands to places like the navigator or editor is conceptually similar to what you would do in eclipse. What's different is that we currently avoid any specification of "well known UI contribution locations" such as toolbar groups, known menus, etc. It may come to this, but today we focus on semantic elements in a page anatomy. Plugins can contributor editor and navigator commands, or primary navigation links, but where these are represented is handled internally. INSIDE Orion, our pages are still doing some grouping/separation/ordering of command contributions, but at least for now, plugin contributions of the same are more limited, and our pages figure out where contributed commands belong on the page. This difference gives us the flexibility to evolve the UI, and we hope provide more flexibility to those who might wish to completely reskin Orion.
Another point is that contributions that might be considered command contributions in Eclipse are more appropriately described as links in Orion. If you want to link to content related to a particular Orion task, or an individual resource, you shouldn't need to write a command to do so. Instead, you can supply links in various ways, so that existing Orion content (editor content, page text, command menus) include links to your contribution.
Don't Call Us, We'll Call You
Due to the distributed nature of Orion plugins, most of our UI contributions are "don't call us, we'll call you." For example, a plug-in can contribute a command (with keybinding, icon, tooltip), or register a navigation link that links back to the plugin. But Orion hooks it up and calls the plugin when it's time to do something. (Today) there is not much interaction where the plugin decides it's time to talk to Orion.
It's clear that we have some missing pieces.
Visual Plugin-provided content inside an Orion page
Mailing list discussions have shown the need for a tighter level of integration than we have today. It's all well and good to link from Orion to a plugin's custom view and editor, but plugin developers want these pages to look like Orion pages. This means:
- Orion banner, footer, branding
- Access to Orion toolbar
- Access to status and progress messages
- Access to user preferences
This would be the first case of a UI extension where instead of "don't call us we'll call you" a plugin starts talking to Orion services, such as "open this dialog" or "here's my status message." The services needed to do so are there already, but we haven't packaged up the minimal code needed on the plugin side to call them, and work through any security scenarios.
If we defined a new extension point (imagine "orion.page.content") in which plugins could run visually inside an iframe and talk to "shell services" is this enough? And are we then inventing our own gadget container? If a plugin can fill the page content visually, why not fill just a small box and let the user mix and match the boxes?
Exposing Service APIs
If we start supporting scenarios where visual plugins initiate calls to Orion services, how is this scenario different from the existing extension points? For example, it seems appropriate for a visual plugin to have access to command definition and rendering inside its content. But it seems inappropriate for a link scanner extension decide to grab the command framework directly and insert additional URL or key bindings into the hosting page rather than using the extension points to do so.