Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: ecf-dev Digest, Vol 16, Issue 23

Looks good Scott.  What providers (if any) will need new connectWizards?


On Nov 22, 2006, at 12:00 PM, ecf-dev-request@xxxxxxxxxxx wrote:

Send ecf-dev mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ecf-dev digest..."

Today's Topics:

   1. Some thoughts (and code) for ECF UI (Scott Lewis)


Message: 1
Date: Tue, 21 Nov 2006 10:37:24 -0800
From: Scott Lewis <slewis@xxxxxxxxxxxxx>
Subject: [ecf-dev] Some thoughts (and code) for ECF UI
To: "Eclipse Communication Framework (ECF) developer mailing list."
Message-ID: <45634764.40607@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Folks,

I wanted to let everyone know that I've been adding to
org.eclipse.ecf.ui plugin to make it easier to build clients.

I've created two new extension points:

Configuration Wizards:  org.eclipse.ecf.ui.configurationWizards
Connect Wizards:  org.eclipse.ecf.ui.connectWizards

These two extension points allow other plugins to register themselves as
providers of wizards for doing configuration and connection.  So, for
example, if you are building a new provider, and you want to make
available a user interface for connecting/authenticating for that
provider, then you would register itself as an implementer of the
connectWizards extension point with the following in it's plugin.xml:

            name="My Client Connect Wizard">

Note that the class "" must implement the org.eclipse.ecf.ui.IConnectWizard interface. This interface extends IWizard. Also, the containerFactoryName (in this case "")
must match the containerFactory name specified in the containerFactory
extension for this provider so that there is a 1-1 association between
the provider implementation and the provider wizard UI.

So, for example, with this provider you would setup a containerFactory
extension like this:

            description="ECF Generic Client"

With these extensions in place, clients can call the following code to
open the MyClientConnectWizard:

new ConnectWizardDialog(shell, workbench, new
ContainerHolder("", container)).open();

And that's it.

To do IContainer creation and configuration via the registered wizard:

ConfigurationWizardDialog cwd = new ConfigurationWizardDialog(shell,
IContainer newContainer = cwd.getResult().getContainer();
if (newContainer != null) // successful

So here's the whole sequence for creating and connecting an arbitrary
client, assuming that the provider has setup both configuration and
connection wizards with the above extension points

ConfigurationWizardDialog cwd = new ConfigurationWizardDialog(shell,
IContainerHolder configurationResult = cwd.getResult();
IContainer newContainer = configurationResult .getContainer();

// setup newContainer with adapters, listeners, etc

new ConnectWizardDialog(shell, workbench, configurationResult).open();

Any thoughts/comments on any of this are welcome. Note that we can now put libraries of wizard creation support classes (e.g. for providers to
use) in org.eclipse.ecf.ui.wizards and support actions in
org.eclipse.ecf.ui.actions. Then providers will simply pick an existing wizard that we've created for doing configuration or connect...or extend
it, or write their own.   Thanks to Remy Suen for already providing a
connect wizard (org.eclipse.ui.wizards.GenericClientConnectWizard).




ecf-dev mailing list

End of ecf-dev Digest, Vol 16, Issue 23

Back to the top