Bugzilla – Full Text Bug Listing
| Summary: | Opening a window from a plug-in | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> |
| Component: | Client | Assignee: | Szymon Brandys <Szymon.Brandys> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, ken_walker, malgorzata.tomczyk, mamacdon, simon_kaegi, susan |
| Version: | 1.0 | ||
| Target Milestone: | 4.0 M1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Szymon Brandys
Commands support callback or hrefCallback. Could they also support returning url of UI, let's call it uiCallback? uiCallback would return a url for Orion to open within an IFrame in a modal dialog. I could imagine orion.edit.command plugged in this way. It would return url to open in an IFrame. When the editor action is triggered, the url is returned and Orion opens it in a modal dialog. At the end, a message is posted that can be understood only by orion.edit.command handler and Orion closes the dialog. Can't it work this way? The internal view of commands (callback, hrefcallback, etc.) will be affected, but I prefer to first focus on the plugin's view of the world. Right now we have
run(selectedText, text, selection, resource)
which returns an object with
and instead focus on the plugin API. Right now we don't expose a uriTemplate at all in orion.edit.command so we have the ability
(In reply to comment #2) Sigh...somehow pushed the button before finishing. Trying again: > The internal view of commands (callback, hrefcallback, etc.) will be > affected, but I prefer to first focus on the plugin's view of the world. > Right now we have > run(selectedText, text, selection, resource) > which returns an object with properties "text" and an optional "selection" So I think that this method would need to take a new property, something like uiURITemplate??? Then internally we can make this work inside a modal popup, etc. We may need additional attributes to control size or position, but we can try some defaults first. The communication back to the editor from the delegated UI is something we should talk to Simon about. Szymon and I have been playing with the picker plugin. We hacked together something that works in the editor, obviously it needs to be generalized. The plugin is at https://raw.github.com/szbra/GPicker4OEdtr/poc/index.html (this is the "poc" branch of this plugin) Then you need to checkout the "delegatedUI" branch of org.eclipse.orion.client Lots of hacks here but it demonstrates the basic premise. To me the million dollar question is: what is the shape of the API where the plugin says "hey host page, I have a result." We implemented this with a raw post message that is handled in the editor page. Instead I imagine that we have something like provider.requestPageService("delegatedUIResult", {myResult: "foo", etc....}); This code would use a new plugin registry "method" called "pageService" to dispatch the request to some orion service. I started hacking in plugin.js and pluginregistry.js to do it this way, but I could not figure out how the plugin registry would know about the service registry, and it seems to me that we need is communicate info from the plug-in to some in-page service. This would make implementing the progress service trivial (bug 390708) and many other page services that we decided to expose. Once we defined API for the notification, then we could generalize the delegated UI iframe creation so that it's not just in editor commands, but is actually some general service that can be requested anywhere. I'm setting the target to 2.0M1 and I believe we can have something working by this date :) (In reply to comment #4) > This would make implementing the progress service trivial (bug 390708) and > many other page services that we decided to expose. See bug 390708, comment 7. I think we should re-think whether progress service should be exposed in plug-ins or not. I talked to Simon about this. He believes we don't need something as generic as what I said in comment 4. We don't need a "talk to Orion service" api yet. Instead, we will define the postMessage API that a delegated UI would use and beef up our listener so that we only listen to the iframes we know about. (I had tried to do the latter with event.target.location but reaching into an iframe's properties is not allowed). Simon is taking this bug for beefing up the listener and from there I will generalize/add some display properties to the service. Great. Susan, when you start adding display properties, I'll update to GPicker example and rework other examples from Orion Hackathon. (In reply to comment #8) > Great. Susan, when you start adding display properties, I'll update to > GPicker example and rework other examples from Orion Hackathon. Simon, what do we do with it? I would like to rework other UI examples and document it in the wiki. per email discussion, I have updated the original proof of concept hack and pushed to master. Commit is http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=1e98c7f1b0e68fb60fc26718db3a0389b94fe8bc Some things to note: - we decided that for now (2.0) we will only support delegated UI for editor commands, learn how it's working, and then consider generalizing it later. So for now the implementation is in editorCommands vs. being in some generic module. - the picker example doesn't care about the selected text, text content, etc. So this proof of concept hack does not pass any of that information to the iframe. Simon and I discussed that a better way to do this might be to have the service.run implementation provide the uriTemplate (rather than a service property) so that it could build a URI that includes contextual information about the selection, etc if needed by the UI. That means we would always call service.run and then check for a uriTemplate passed back instead of a result. I will wait to hear from Szymon whether this is needed by any of the examples. - still needs some polish by Simon as far as having a secure message listener. Also, as discussed in comment 8, we might want some properties to help determine the preferred size of the iframe. I considered positioning the iframe relative to selected text, but that might not be good for a larger iframe. Something to think about. I will assume Szymon will drive the requirements here based on hackathon examples. Just let me know what is needed. (In reply to comment #11) > Also, as discussed in comment 8, we might want some properties to help > determine the preferred size of the iframe. I considered positioning the > iframe relative to selected text, but that might not be good for a larger > iframe. Something to think about. I will assume Szymon will drive the > requirements here based on hackathon examples. Just let me know what is > needed. Properties like preferred size would be good to have. Also the picker example doesn't care about the selected text just because we did not have that at the time it was made. If we could pass the selected text, the picker could be populated with the selected text on show. Simon has cleaned up iframe creation and listener removal. I'll take this bug now and change the flow so that the run method gets the uritemplate of the delegated UI rather than ahead of time. This way, the plugin could decide to build selection or content info into the iframe's URL. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=2a8bf65768a3ff48b4545e0d262b4a63fda2626f This commit moves the uri retrieval to the service implementation and allows width and height properties. I updated the google picker poc branch to use the new API. However I'm having a problem testing it, the service.run method never runs, and I got lost in the bowels of the plugin startup sequence events. Szymon said he'd look at the plugin. Updated doc in http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_editor#orion.edit.command However we should eventually point to a full example from this doc. Szymon is going to work on this. Moving bug to Szymon for now. Examples will be ready by RC1. I fixed the problem in editorCommands.js and now it works for me. I will update the doc and write a blog post about this new cool thing. Thanks! I made some further changes to the plug-in. Now the welcome page allows to install the plug-in into OrionHub or provided Orion instance. Moreover the picker is populated with editor selection. (In reply to comment #18) > I made some further changes to the plug-in. Now the welcome page allows to > install the plug-in into OrionHub or provided Orion instance. > Moreover the picker is populated with editor selection. cool! I added a link to the example and its source code here http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_editor#Google_Picker_example Feel free to change/update. Fixed. |