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

[John J Barton <johnjbarton@xxxxxxxxxxxxxxx>]

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