Re: [orion-dev] Need help with creating an extension point

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Stepping back a bit, I'm wondering what
the overall UI experience of the command line will be, and how it will
fit with other pages. Ignoring any security or architectural limitations
for a minute, would it look like:

1) A console "Section" embedded
in other Orion pages, such as the editor or navigator.
2) A single Orion console page (say
http://orionhub.org/console/).
This single page would allow you to interact with all the various console
extensions you have available.. Git, Cloud deployment, Rails console, etc.
3) Individual console pages for various
tasks. For example, http://mygithost.org/console
to interact with a Git repository, http://cloudfoundry.org/console
to interact with a deployed cloud application, etc.
4) Something else?

To me, 3) seems closest to the current
Orion approach of tightly focused individual pages rather than generic
pages. It's also more scalable as it wouldn't have to fit all the possible
console functionality a user might want into a single page. In this setup,
the services would live in page and wouldn't have the restrictions on security,
cross-frame communication, etc. Coming from Eclipse, we sometimes need
to fight against the "everything is a plugin" mindset. In Orion,
plugins provide fairly focused/restricted functionality, and richer services
live directly in-page. You can still use the Orion service model in cases
where the services are registered in page and are able to provide richer
behaviour than "give me a JSON" type functions. We haven't given
much thought on how to package and reuse richer chunks of services outside
of plugins yet, so maybe that is a weak point we'll need to work on.

John

Kris De Volder <kdvolder@xxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

03/02/2012 09:27 PM

Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	Re: [orion-dev] Need help with creating an extension point

I was thinking more of something like we
do 'vmc apps'. The command produces a table of apps:
  - html table would be nicer than ascii table
  - it would be cool to have buttons in the table to start / stop
/ delete listed the apps.

So for a simple case it only boils down to nicer formatting of the output
(html can do a better job than plain ascii text).

But for the more ambitious case.... I'm talking about breaking the mold
of a traditional command line where you type a command, get an answer back,
type another command. 
Instead you type a command and the answer you get back provides stuff like
links, buttons... etc. Blurring the line between what's a CLI and what
is GUI.

That said, for now I'm happy enough just assuming the command output is
plain text and dumping it all in a <pre> element. But that doesn't
show a lot of imagination and isn't very 'webby'.

Kris

---

for this particular case (UI for a command)
I imagine we can get by without injecting HTML.
We are already doing this in a couple places:
- command slideouts generate UI based on parameter descriptions/types
- settings page generates UI for settings based on setting types

If we are just talking about simple things like text fields, toggles, choices,
etc. I think we should be able to support this in a secure way.
It's not unlike those jface field descriptors, etc...from eclipse.

susan

Simon
Kaegi ---03/02/2012 10:28:01 AM---Yes probably. I just don't think we can
secure a HTML/JS/CSS UI sent over postMessage and injected i

From: Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 03/02/2012 10:28 AM
Subject: Re: [orion-dev] Need help with
creating an extension point
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

Yes probably. I just don't think we can secure a HTML/JS/CSS UI sent over
postMessage and injected in page so at that point one option would be to
float an IFrame for good or bad. It's probably safe to say that work on
visual plugins will be in plan for 0.5 however I wouldn't want to set expectations
especially on the ability to interact with page services until we get a
chance to try/fail cycle a little. 

-Simon

John
J Barton ---03/02/2012 12:52:44 PM---Sounds like another example of a feature
that wants to 1) be a plugin 2) have a UI. Sending the UI o

From:	John J Barton <johnjbarton@xxxxxxxxxxxxxxx>
To:	Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:	03/02/2012 12:52 PM
Subject:	Re: [orion-dev] Need help with creating an extension point
Sent by:	orion-dev-bounces@xxxxxxxxxxx

---

Sounds like another example of a feature that wants to 1) be a plugin 2)
have a UI. Sending the UI over the postMessage() is just going to hurt.

jjb

On Fri, Mar 2, 2012 at 9:46 AM, Kris De Volder <kdvolder@xxxxxxxxxx>
wrote: 
> I haven't looked at GCLI in some time
so what's above is likely sub-optimal nonetheless I think it shows roughly
what we need to do. 
> What do you think? Does this make sense.

I think it is a good place to start. Eventually we probably will need to
refine it. One thing that really appeals to me in gcli is that it is
more sophisticated than a 'terminal' that just renders text. The result
of a command could, for example, be a full blown UI rendered
inline in the console.

Thus the render function should really be considered part of the command
implementation, and should be able to have access to
other services on the page. If it returns html bits and pieces. It may
also need some control over how those bits get displayed with CSS.

In gcli this is somewhat easy and informal because there isn't such a clear
line drawn in the sand as there is in orion. So objects / functions pass
freely 
back and forth, get access to global variables like 'document' and can
directly manipulate the dom if they wish to do so.

But for now some simple support for rendering textual results in a terminal-like
interface will be enough (although I would be rather disappointed 
if this means we'd be limited to that in the future :-)


> Kris if you want to open a bug around this stuff and point me at a
commit I'd be happy to push it to our repo and work with you on it.

I'll do some more work on this today. Hopefully by tonight I will have
something, still in rough shape, but with the vmware specific bits removed
(and 
contributed as service/extensions) by tonight. Then I'll put it up somewhere
public and open the bug. 

Thanks for the feedback,

Kris

---

Hi Kris,

I'm interested in helping out on creating a page to explore all things
GCLI. I'm hoping we can use the debug page Grant created as a basis and
then iron out the details of a command extension. As you not the GCLI bits
would live on the page so not contributed via plugin. (It also means we
need a CQ)

All service calls are inherently asynchronous (even if they're underlying
implementation is synchronous) so at least from the code snippet you showed
integration should be fairly easy.
So, imagine we define an extension like "orion.shell.command".
The idea would be that a plugin would register something like the following:


function SomeCommand() {}
SomeCommand.prototype = {
exec: function (params) {
// if the call is async return a "then"-able promise / e.g. dojo.Deferred
or some object with a "then" function
// for a sync call just return it immediately. The plugin architecture
and implementation looks after the details.
}
};

var service = new SomeCommand();
var provider = new eclipse.PluginProvider();
provider.registerServiceProvider("orion.shell.command", service,
{
name: 'vmc login',
description: 'Login to currently selected target',
manual: 'Login to currently selected target',
params: [{
name: 'email',
type: 'string',
description: "User's email address"
}, {
name: 'passwd',
type: 'string',
description: 'Password'
}]
}
provider.connect();

---

In the page where GCLI lives you might have something like...

var allReferences = serviceRegistry.getServiceReferences("orion.shell.command");

for (var i = 0; i < allReferences.length; ++i) {

var service = serviceRegistry.getService(allReferences[i]);
if (service === null) continue;

gcli.addCommand({
name: allReferences[i].getProperty("name"),
description: allReferences[i].getProperty("description"),
manual: allReferences[i].getProperty("manual"),
params: allReferences[i].getProperty("params"),
exec: function (params, context) {
var promise = context.createPromise();
service.exec(params).then(function (result) {
promise.resolve(render(result));
});
return promise;
}
});
}

--

I haven't looked at GCLI in some time so what's above is likely sub-optimal
nonetheless I think it shows roughly what we need to do. What do you think?
Does this make sense.
Kris if you want to open a bug around this stuff and point me at a commit
I'd be happy to push it to our repo and work with you on it.

-Simon 







Kris De Volder ---03/01/2012 06:35:38 PM---Hi all, This corresponds to
my second use case.

From:	Kris De Volder <kdvolder@xxxxxxxxxx>
To:	Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:	03/01/2012 06:35 PM
Subject:	[orion-dev] Need help with creating an extension point
Sent by:	orion-dev-bounces@xxxxxxxxxxx

---

Hi all,

This corresponds to my second use case.

I'm now already going on the assumption that the "gcli console"
itself won't actually be itself an orion plugin. 
Previous discussion seems to indicate this isn't possible, and also it
probably isn't necesary 
if the core gcli functionality is going to be contributed back to orion.

However before it can be contributed back I need to figure out how it can
be made extensible... so that contributors can define new gcli commands,
types and fields.

This is necessary because only some of what I've implemented is of general
use. Whereas other commands are specific to cloudfoundry support and don't
belong in a 'core orion example server'. 

It would also be nice if git commands could be contributed via this mechanism
rather than 'baked in' with the core console implementation.

I am hoping the orion plugin mechanism and/or service registry model *will*
work for this use case. I'm hopeful because it probably is somewhat similar
to the existing 'orion.page.commands' service. 

But I'm having a hard time figuring out how to make this work (with or
without using the orion services/plugins model).

gcli provides three 'extension points':
 (1) adding commands: define parameters for a command and an exec function
 (2) adding types: define how to parse/unparse different types of params,
'parse' also defines how to compute completions.
 (3) adding fields: define UI for editing parameters of a given type.

In terms of difficulty to wrap these mechanisms as orion services I'd say
that
 3 > 2 > 1

So let's start with just the easy case first: adding commands.

A typical command definition will look like this:

gcli.addCommand({
name: 'vmc login',
description: 'Login to currently selected target',
manual: 'Login to currently selected target',
params: [
    {
name: 'email',
type: 'string',
description: "User's email address"
    },
    {
name: 'passwd',
type: 'string',
description: 'Password'
}
],
exec: function (...) {...}
});

A typical exec function: (for a command that has some asynchronous execution)

function (args, context) {
   var promise = context.createPromise();
   doSomething(function (result) { //callback
       promise.resolve(render(result));
   });
   return promise;
}

The 'render' function turns the result into either a dom node or html text
string.

The hard part (for me at least :-) in turning this into something like
a 'service' registered 
by a plugin is the exec function. As was discussed on the orion call 2
weeks ago, 
functions can't be passed through the 'JSON.stringify' barrier.

I could imagine this 'exec' function being part of the service implementation.
So the function itself
wouldn't need to pass through the JSON barrier. However, its parameters
would.

The args object is (upto now) no problem. As far as I know it is usually
pure data (although this may depends on the types of the parameter are
and how its parse function is implemented). The context object I don't
know how to deal with. It provides richer API including a 'createPromise'
function that is needed to support asynch style command executions (and
that's needed for my use case which executes commands via server-side http
APIs).

I'm looking for three possible things from this post:
 1) suggestions on how/if something like this could work within the current
orion architecture
if the answer to 1 is that it isn't possible:
    2) starting a discussion on how to modify the architecture
to make it possible 
    3) suggestions on how to make it work within the current
limitations (i.e. an acceptable/reasonable way to bypass the limitations
of the current architecture).

Kris
_______________________________________________
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
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev