Bug 372914

Comment 1 Susan McCourt 2012-02-29 16:30:35 EST

I'll work with Simon on the shell service API.  We won't expose the registry and the raw services.  The idea is to expose an object that can be called to do the common things.

Having exposed the shell service object, we can then look at the "consumable chrome" idea where a page stays where it is and uses the chrome/shell service in a js library.

Comment 2 Susan McCourt 2012-03-06 01:49:01 EST

I'm going to use bug 362067 (online image editing) as the first use case, since I know what to do and it gives us something to show/another integration scenario.  What's cool is that I've gotten pretty far defining one new service extension and using the existing editor/open with concepts.  

I have defined a very simple "orion.page.content" service extension that looks like this:

provider.registerServiceProvider("orion.page.content", {}, {
	id: "orion.pixlr.content",
	name: "Pixlr",
	uriTemplate: "http://pixlr.com/editor/?image=" + qualifyURL("..") + "{Location}"});

A new page called content.html parses the page URL and looks for the service extension id that matches the "contentProvider" id in the URL. So we register an editor extension like this:

provider.registerServiceProvider("orion.edit.editor", {}, {
	id: "orion.pixlr",
	name: "Pixlr Image Editor",
	uriTemplate: qualifyURL("../content/content.html#") + "{Location}" + ",contentProvider=orion.pixlr.content"});

That will load the content page, look up the "orion.pixlr.content" contribution and use its uritemplate to load the iframe.

A corresponding open with command looks like this:

provider.registerServiceProvider("orion.navigate.openWith", {}, {
	editor: "orion.pixlr",
	contentType: ["image.gif", "image.jpeg", "image.ico", "image.png","image.tiff"]});

This means I can already click on an image in the navigator, choose Open With->Pixlr, and get a page with the correct image loaded, correct breadcrumb, related pages, etc.  Screenshot is here:
https://bugs.eclipse.org/bugs/attachment.cgi?id=212112

Next step is to figure out save.  I've got some ideas in bug 362067.  Note that by hosting the iframe in an Orion page, we can get around the save problem by implementing save in the "chrome" page and just get the file contents from the iframe. I should get save working tomorrow and then I'll release all of this.

So far the only shell services implemented are provided for free by the containing page using the metadata described in the URI template.  We can go pretty far just knowing that this iframe is manipulating a workspace resource.  With that knowledge, we can build a breadcrumb, load related pages, etc.

Comment 3 Susan McCourt 2012-03-06 02:33:11 EST

ok, this is cool.  I moved the plugin to github to prove that you can indeed glue together Orion and some third party site without having to host the plugin in Orion or at the third party.  It required adding a new built-in parameter to the URI template called HostQualifier. This is needed so we can pass fully qualified workspace names to the third party API (which image to load)

provider.registerServiceProvider("orion.page.content", {}, {
	id: "orion.pixlr.content",
	name: "Pixlr",
	uriTemplate: "http://pixlr.com/editor/?image={HostQualifier}{Location}"});

and also so that the plugin can build an href that loads the "content loading page" in the running Orion instance.

provider.registerServiceProvider("orion.edit.editor", {}, {
	id: "orion.pixlr",
	name: "Pixlr Image Editor",
	uriTemplate: "{HostQualifier}/content/content.html#{Location},contentProvider=orion.pixlr.content"});

Comment 4 Kris De Volder 2012-03-06 13:59:55 EST

That sounds good. The gcli page will probably be able to fit in that model. The 'resource' it is associated with would be its working director.

We also want the option to change the 'current resource' without triggering a page reload. 

Right now the 'current-directory' is tracked by getting and setting its URI into/from dojo.hash. 

I mention this because I imagine it may not be something that you considered for the image editor scenario.

Kris

Comment 5 Susan McCourt 2012-03-06 19:54:15 EST

(In reply to comment #4)
> That sounds good. The gcli page will probably be able to fit in that model. The
> 'resource' it is associated with would be its working director.
> 
> We also want the option to change the 'current resource' without triggering a
> page reload. 
> 
> Right now the 'current-directory' is tracked by getting and setting its URI
> into/from dojo.hash. 
> 
> I mention this because I imagine it may not be something that you considered
> for the image editor scenario.
> 
> Kris

I thought about it a little but my scenario doesn't test it.  Right now I listen to hash change but I reload the iframe (because the content provider id could have changed) and everything else when it happens.  That might not be what you want.  It would probably work but you would lose your state.  We can work on this together.

I've released a rough first cut at this if you want to try it to see if it works at all for your case.

You can basically copy the strategy used by my pixlr plugin at github:

http://sfmccourt.github.com/plugins/pixlr/pixlrPlugin.html

Comment 6 Susan McCourt 2012-03-17 01:26:17 EDT

The save hook is now working.  The workflow is certainly not ideal and there are many improvements to be made, but I think we should open new bugs to evolve this extension as people try it.

Comment 7 John J. Barton 2012-03-18 14:51:01 EDT

I attempted to use this feature:
https://github.com/johnjbarton/atopwi/blob/orionPlugin/orionPlugin.html
but failed. 

I had to load the plugin 3 times to get it to show up. The title and info in the Settings page is not correct, see bug 374604.

I did not see changes in the Orion UI, but then I am unsure what to look for. I did look in the OpenWith menu on a .html file, but nothing other than OrionEditor appears.

Comment 8 Susan McCourt 2012-03-19 13:33:31 EDT

(In reply to comment #7)
> I attempted to use this feature:
> https://github.com/johnjbarton/atopwi/blob/orionPlugin/orionPlugin.html
> but failed. 
> 
> I had to load the plugin 3 times to get it to show up. The title and info in
> the Settings page is not correct, see bug 374604.
> 
> I did not see changes in the Orion UI, but then I am unsure what to look for. I
> did look in the OpenWith menu on a .html file, but nothing other than
> OrionEditor appears.

hmmm...you should see an open with for your "Chrome Devtools" when an html file is used.  

I did notice that the href is overly complicated, it is using some of the pixlr API.  You should be able to get by with

uriTemplate: "{OrionHome}/atopwi.html?debuggee={OrionHome}{Location},contentProvider=chrome.atopwi.content"});

Comment 9 John J. Barton 2012-03-19 15:33:58 EDT

(In reply to comment #8)
> hmmm...you should see an open with for your "Chrome Devtools" when an html file
> is used.  

What means "file is used"? What operations and where do I look?

> 
> I did notice that the href is overly complicated, it is using some of the pixlr
> API.  You should be able to get by with
> 
> uriTemplate:
> "{OrionHome}/atopwi.html?debuggee={OrionHome}{Location},contentProvider=chrome.atopwi.content"});

I made this change, but it did not help of course, since my plugin is never attempted.

Where can I look for info on the {variables}?

Comment 10 Susan McCourt 2012-03-20 11:57:27 EDT

(In reply to comment #9)
> (In reply to comment #8)
> > hmmm...you should see an open with for your "Chrome Devtools" when an html file
> > is used.  
> 
> What means "file is used"? What operations and where do I look?

Look in the Open With extension for an html page.
If you host your plugin on git hub pages, I can try to load it and see if I can make sense of it.

> Where can I look for info on the {variables}?

Unfortunately, right now you have to look in content.js
The key variables are {OrionHome}, {Location} and if you want to save data back to the workspace, {SaveURL}.  Look for me on IRC if you have questions.  I plan to doc all this in the next few days.  The variable support is ad hoc right now, see bug 373450.

Comment 11 John J. Barton 2012-03-20 16:25:09 EDT

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > hmmm...you should see an open with for your "Chrome Devtools" when an html file
> > > is used.  
> > 
> > What means "file is used"? What operations and where do I look?
> 
> Look in the Open With extension for an html page.
> If you host your plugin on git hub pages, I can try to load it and see if I can
> make sense of it.

Unfortunately this isn't practical. As you can see from the readme, the plugin relies on a web page that combines several git projects including orion.client.

Comment 12 John J. Barton 2012-03-21 19:51:23 EDT

Is any part of this important to the orion.page.content service?
    uriTemplate: qualifyURL("../content/content.html#") + "{Location}" +
",contentProvider=orion.pixlr.content"});

I want to use standard URI search parameters and the comma...= confuses my code.

Comment 13 John J. Barton 2012-03-21 20:05:35 EDT

Created attachment 213033 [details]
Orion Editor inside of Chrome Devtools inside of Orion page

Comment 14 Susan McCourt 2012-03-21 23:25:56 EDT

(In reply to comment #12)
> Is any part of this important to the orion.page.content service?
>     uriTemplate: qualifyURL("../content/content.html#") + "{Location}" +
> ",contentProvider=orion.pixlr.content"});
> 
> I want to use standard URI search parameters and the comma...= confuses my
> code.

Yes.  the content.html page is page that is loading the inner iframe.  {Location} tells it what file it has been opened on.  The ",contentProvider=xxxx" part tells it the id of the "orion.page.content" extension that it should load.

I agree, it gets pretty hairy when the page is expecting one format and then we are using something a little different.  That's what I was trying to get at in bug 370903 comment 5.

Can you either open a new bug about this or add some information to bug 370903, which covers the general idea of how we can build URI's using our conventions and someone else's?