Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orion-dev] Fw: A complex plugin use case (number 1)

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

Inactive hide details for Mike Wilson ---02/24/2012 06:57:38 AM---> Something to discuss after 0.4 is declared?.... Sure. As loMike 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.


Inactive hide details for Susan Franklin McCourt ---2012/02/23 23:06:20---I think saying we don't visual plugins is a strong stSusan 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

Inactive hide details for John J Barton ---02/23/2012 05:41:33 PM---This description sounds a lot like my Orion plugin player pJohn 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

GIF image

GIF image


Back to the top