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

[John J Barton <johnjbarton@xxxxxxxxxxxxxxx>]

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