[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orion-dev] A complex plugin use case (number 1)
|
Since this looks vaguely like an opening for some reconsiderations, here are some ideas and thoughts based on my experiments:
The json/REST API on the server is a total win. Mostly I can just read the json in the debugger and code off the results. (To be sure, I've just started on my first use of 'task' which is a complication I don't have a lot of experience with). Below I will be critical of the web-page-per-task model, but I want to point out that I believe the task model helped organization of the REST API. That was a big win.
Despite my complaints about the non-reciprocal plugin system, the Orion plugin system is very successful. In the browser world, web-intents is ramping up quickly. They are interested in supporting iframes as well as inter-page data exchange. There is a lot of potential for leveraging and influencing web-intents based on Orion's track-record and use case. I know Simon is keen on this but we need to take action soon. Again foreshadowing my discussion below, I think the web-page-per-task model has a lot to offer in the integration of outside tools via web-intents++.
We should re-discuss the issues involved in visual iframes. The
browser world has changed since Orion started and more important it can
change again before your 1.0. In particular we should push on tab-management, a weak point in the browser platform.
Organizing the modularity around a web page per task has two significant downsides.
First it makes re-use of in-page resources very difficult for plugin authors. Because the Orion team organizes work around the page, assets in the page that could be building blocks for outside developers are hard to find/re-use. The down hill path is to start over and create a completely independent UI working against the common server. To be sure this is also a big plus compared to Eclipse, where it was "the eclipse way or the highway" so to speak. But a core set of css, images, and widgets would make extension much easier.
Second, the web-page-per-task results in a "micro-task-oriented development environment". The user 'task' is "develop a web app", which breaks down into a workflow, some elaboration of edit, test, debug, cycle, commit, communicate, etc. The web-page-per-task model zeros in on one of the steps, evolving richer and more elaborate ways accomplish the step. The workflow, ultimately critical to the user, not only gets less attention but it is actually damaged by the success in improving the individual pages. I know that Susan in particular has been trying to address this issue but I wonder if it can be solved within the current model.
However, I don't advocate switching to a "reinvent eclipse" model. I don't think we need a single model. Instead I suggest leveraging Orion's strengths and potential in build a few 'workflow-oriented' apps, forming a higher but not necessarily uniform layer on top of the current pages. This layer would be 'opinionated' rather than generic. They would deliberately limit the users options within a given micro-task to maximize flow; they would fallback to the current layer of pages when the user need more options/power.
Two concrete examples I'm working on: 1) a combination logging/debugger/editor page where opening the stack frame reveals an editor rather than a link to an editor, 2) a combination site/git page which enforces a server layout and a specific branch strategy. Both examples cross the current 'task' boundaries and yet do not cover the uses cases of any one task.
I suppose this layer is analogous to eg Mylyn in eclipse. The amount of development effort however is much lower because Orion is a better platform, and yet the end result is less like an Orion plugin than a completely new web app. That is where my previous points come back into play: some combination extensible plugins, visual iframes, and graphical assets could make this layer more 'orion like' and easier to develop. The result would be a better workflow for common use cases without leaving the user stranded because the workflow layer looks and feels so different from the task layer.
jjb
On Fri, Feb 24, 2012 at 6:56 AM, Mike Wilson
<Mike_Wilson@xxxxxxxxxx> wrote:
> 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 st]()
Susan Franklin McCourt ---2012/02/23 23:06:20---I think saying we don't visual plugins is a strong statement.
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 p]()
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
