Re: [orion-dev] Fw: A complex plugin use case (number 1)

[Andrew Eisenberg <andrew@xxxxxxxxxxxx>]

Hi Susan,

I didn't want to derail the call, so I didn't mention this earlier.  I tried your pixlr plugin.  As a concept, the visual plugin looks nice, and opens up some big possibilities.

However, the pixlr plugin itself could not load the image I passed to it.  I'm guessing this is because I am running Orion locally and the file:/ url for the image is being sent to pixlr on the remote server, which cannot be accessed.

This kind of problem will likely happen if you are behind a firewall and it shows a bit of a limitation on how information can be shared between the orion instance and the plugin.

I'm not sure of a good solution for this, but I wanted to let you know about the problem I had.

On Tue, Mar 6, 2012 at 5:52 PM, Susan Franklin McCourt <susan_franklin@xxxxxxxxxx> wrote:

hi, all. Sorry for the length of this, but I wanted to give a status update on what's happening with respect to visual plugins.
I've been doing some hacking to further explore the visual plugin idea, and it's definitely exposing issues/questions. I've released enough code that I think jjb and Kris could potentially hack around with it and provide feedback. Here are some links, things to look at.

The wiki page I mentioned before [1] talks about the general issue and the multiple ways we could approach the issue of having remote content that looks like Orion and links to other parts of Orion in interesting ways (via shared navigation, related pages, etc.) The idea is "who's in charge?" The content or Orion?
- if Orion is in charge, then we can build an Orion host page that delegates the content to some plugin/other site.
- if the content is in charge, it could consume some Orion code that can inject the shared page elements, to make itself look more like Orion and link back to Orion.

I think the former approach is especially useful when you are trying to integrate an existing web app that you can't change, such as an online editor. The latter approach may make more sense when the content is more knowledgeable about Orion, desiring a richer integration with the Orion chrome.

We decided to start some early experiments in this bug [2]. Please cc: on the bug if you are interested in the topic. The bug starts with the "Orion is in charge" scenario. This is a little more expedient for early experiments. If orion is in charge, then the hosting page (orion.eclipse.org/content/content.html) already has access to the orion extension registry, etc., and can call the existing code that creates the common page elements. This immediately lets us build a shared header, related links, search scoping, etc. Long run, I think we'll support both scenarios, but I'm hoping that what we're learning about how the content and common page code communicate is applicable for both scenarios. It will be a matter of plumbing and packaging up the functionality, "who calls who," etc.

All that said, I released some very early support of an "orion.page.content" service extension that delegates the page content to an iframe. My initial example for this is trying to embed the pixlr image editor. [3] To try it out, you can install the pixlr plugin on github [4] and then you should be able to use the navigator "open with" to open either pixlr or pixlr express.

The integration of the plugin is very coarse (ie...note the menu bar within the content area). But what I find interesting is that this approach lets a third party (my git hub plugin) integrate Orion with an existing web API without having to modify either. In the past we either download a js library from the web app we like, or put the plugin on their site, etc. The elusive "how do you save to the workspace" issue is still the challenge, but this work is already helping us to think about the problem in terms of small chunks of functionality that might be a win vs. big chunks like "I need access to the entire workspace." [5] I think that in the long run, the pixlr plugin could prove to be an example of a specific subset of delegated content, the "delegated editor."

Hopefully Kris can try integrating the gcli page using this approach and it should illuminate more things we need.

jjb, I'm still digesting your very thoughtful comments on this thread regarding task level pages, higher level workflows, etc. I'm not attempting to address that issue yet, but hopefully there is still something you can play with in this support. Feedback is welcome in the various bugs noted below, or here if you aren't sure where to start.

thanks,
susan

[1] http://wiki.eclipse.org/Orion/Visual_Plugin_Strategy
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=372914
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=362067
[4] http://sfmccourt.github.com/plugins/pixlr/pixlrPlugin.html
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=373443


Susan Franklin McCourt---02/24/2012 10:22:34 AM---As part of our documentation effort this week, I wrote a *very quick* description of our strategy th

From: Susan Franklin McCourt/Beaverton/IBM@IBMUS
To: orion-dev@xxxxxxxxxxx
Date: 02/24/2012 10:22 AM
Subject: [orion-dev] Fw: A complex plugin use case (number 1)

Sent by: orion-dev-bounces@xxxxxxxxxxx

---

As part of our documentation effort this week, I wrote a *very quick* description of our strategy thus far and why we've started out how we have. Apologies if this is all stating the obvious, but I thought it might help give context to our desire to be very conservative as a starting point.

http://wiki.eclipse.org/Orion/Visual_Plugin_Strategy

susan
----- Forwarded by Susan Franklin McCourt/Beaverton/IBM on 02/24/2012 10:19 AM -----

From: Susan Franklin McCourt/Beaverton/IBM
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Cc: Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Date: 02/24/2012 08:22 AM
Subject: Re: [orion-dev] A complex plugin use case (number 1)

---

yes, I meant...next week or so.
When John described his use case, it struck me as classic "20 things" scenario from e4. He needs progress, status, toolbar access, etc. But otherwise would like to live in his own private iframe for content. We've been able to get by so far without "shell sharing" but we definitely need a story. The discussion just happened to come up during the RCx cycle when we are trying to lock things down...

susan

Mike Wilson ---02/24/2012 06:57:38 AM---> Something to discuss after 0.4 is declared?.... Sure. As long as you mean _as_soon_as_ 0.4 is decl

From: Mike Wilson <Mike_Wilson@xxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 02/24/2012 06:57 AM
Subject: Re: [orion-dev] A complex plugin use case (number 1)
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

> Something to discuss after 0.4 is declared?....
Sure. As long as you mean _as_soon_as_ 0.4 is declared. This is a *very* important discussion; i.e. we're not going to be able to declare a 1.0 without knowing what our story will be here.

My take: Up till now, we've been living with the limitations because of the nice security and separation-of-concerns characteristics, and because we wanted to see how far we could push this style. I don't think we ever believed that this would be good enough to handle all use cases though.

McQ.

Susan Franklin McCourt ---2012/02/23 23:06:20---I think saying we don't visual plugins is a strong statement.

From:	Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
To:	Orion developer discussions <orion-dev@xxxxxxxxxxx>
Cc:	Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Date:	2012/02/23 23:06
Subject:	Re: [orion-dev] A complex plugin use case (number 1)

---

I think saying we don't visual plugins is a strong statement.
We don't want a mashup architecture (plugins are rectangle boxes inside Orion).
The use case you described previously (you want the whole content area, you want the common header/footer, status area, etc.) fits in with our original vision of "eclipse application services", "shell sharing" etc. but we've never had a concrete use case to work through.

I realize I never answered your response to my questions...we had just entered RC1 and it's been a very busy time.
My take is that if both you and Kris and running into this, it's something to talk about.
The "content is an iframe, offer some shell sharing services" is a middle ground that is more palatable than the mashup/visual plugin idea.

Something to discuss after 0.4 is declared?....

susan

John J Barton ---02/23/2012 05:41:33 PM---This description sounds a lot like my Orion plugin player project: https://github.com/johnjbarton/

From: John J Barton <johnjbarton@xxxxxxxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 02/23/2012 05:41 PM
Subject: Re: [orion-dev] A complex plugin use case (number 1)
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

This description sounds a lot like my Orion plugin player project:
https://github.com/johnjbarton/orion.pluginPlayer
I abandon it for two reasons,
1) Orion team does not want visual plugins (see my post here with that title)
2) Orion does not (currently?) allow plugins to be extensible.

I personally think the Orion architecture would be clearer and more
powerful if the variable UI content were implemented as visual
plugins. This would allow plugin author to achieve the goals that both
Kris and I desire, a plugin that acts like it is part of Orion.
Equally, parts of Orion can be reused more completely. For example,
the current embedded editor is not very much like the orion editor
page, reducing its usefulness as a component in a non-visual Orion
plugin. I want to create a 'log' page plugin for Orion that would
access the console and lots of other tracing info. In that log I want
to directly embed editors.  With the embedded editor I use now the
user experience will be "oh this looks like an Orion editor but it's
not the same one I use in my other window".

jjb


On Thu, Feb 23, 2012 at 4:23 PM, Kris De Volder <kdvolder@xxxxxxxxxx> wrote:
> Following up on the call from this morning where it was mentioned I'm having some problems packaging up gcli stuff to contribute back, as well as separating the bits that are of general utility in such a way that external plugins can contribute the commands we need to support cloudfoundry and node js.
>
> I'll try to present a use case.
>
> Use case: package as a plugin the following functionality:
>  - contribute a link at the top of the page to open 'my page'
>  - implement this page so it looks like an orion page
>    - headers and footers etc.
>    - body of page contains contributed content
>    - contributed content displays gcli interface with commands like 'pwd', 'cd' and 'ls'.
>
> Needs:
>  - add a link to all pages (easy with 'pageLinks' service)
>  - able to generate header and footers with all the trimmings (bread crumb, search box, tool bar, etc.).
>  - access to the fileService to implement the main functionality of the page.
>
> I implemented something that has the right 'look' and works. But it is done mostly by using code like the navigator and git ui as copy pasting example.
>
> Problem 1:
>
> The first problem I hit when trying to package this as a plugin is how do I handle all the dependencies on orion modules loaded by requirejs if we are not on the same server (relative urls are all broken).
>
> I managed to get something working here only by hard-coding the paths to stuff on the server in requirejs configuration in the plugin page. That's really no good, since it assumes orion server runs in only exactly one place.
>
> Questions:
>
> Is there a better way than hard coding paths to orion requirejs modules into the plugin that uses them?
>
> Problem 2:
>
> After 'fixing' problem I hit a second problem. Although all requirejs modules got loaded... they were having trouble accessing server side rest APIs (cross domain xhr requests I think?).
>
> At this point I gave up and started packaging my stuff as an eclipse plugin instead. This was much easier and I was able to achieve a very clean separation, no orion code was modified at all.
>
> Kris
>
> PS: There's a part 2 to this story (how do I make my contributed stuff extensible itself in the right way. But I'll hold that for later).
>
>
>
>
> _______________________________________________
> orion-dev mailing list
> orion-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev