Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Re: ecf-dev Digest, Vol 16, Issue 23 
Hi Ken,

Ken Gilmer wrote:


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


The following will need new/moved over connect wizards

1.  ECF Generic Client and Server
a. Client: The generic client has one (thanks Remy and Ken). I'm thinking I would create a new plugin: org.eclipse.ecf.provider.ui and move this GenericConnectWizard (and page) over to the new provider plugin (in new plugin to prevent new UI dependencies from being added to org.eclipse.ecf.provider itself). I've been thinking that this should be a general convention for provider plugins...that they don't implement the wizard UI code in the same provider plugin, but rather in a new plugin named (by convention) <provider id>.ui ..e.g. org.eclipse.ecf.provider.ui. Then the providers can be written with servers, clients, and small runtimes (e.g. CDC 1.0/Foundation 1.0) in mind. Let me know what you think of this provider convention (separate ui plugin for the wizards associated with a given provider). Note this is the approach taken for 'team' providers (e.g. CVS, SVN, etc., etc) as well as other parts of the platform so we're not at all without precedent here.
b. Server: The Generic Server will need one eventually, but this is low priority. 

3. XMPP Client

4. IRC Client

5. JXTA Client (and perhaps server)


So to sum up...I think the following should be prioritized:
1. ECF Generic Client -- I (Scott) will work on migrating Remy's dialog code over to the new org.eclipse.ecf.provider.ui plugin today (Thurs). If we want to change these/improve them (their look/feel/layout etc) we can do so. 
2.  XMPP Client -- High Priority
3.  IRC Client -- High Priority
4. JXTA Client -- Med Priority (JXTA provider going through IP review now anyway) 
5. ECF Generic Server -- Low Priority
I think what I'll do is create a wiki page and put this info there, as well as file associated bugs/enhancement requests. Watch for another email on this with a link to that wiki page. If you can sign up for these, please just assign yourself to the forthcoming bug/enhancement request. 

Thanks,

Scott




thanks
ken

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


Send ecf-dev mailing list submissions to
    ecf-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
    https://dev.eclipse.org/mailman/listinfo/ecf-dev
or, via email, send a message with subject or body 'help' to
    ecf-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
    ecf-dev-owner@xxxxxxxxxxx

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."
    <ecf-dev@xxxxxxxxxxx>
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:

   <extension
         point="org.eclipse.ecf.ui.connectWizards">
      <wizard
            class="org.my.client.MyClientConnectWizard"
            containerFactoryName="org.my.client"
            id="my.client.wizard"
            name="My Client Connect Wizard">
      </wizard>
   </extension>

Note that the class "org.my.client.MyClientConnectWizard" must implement
the org.eclipse.ecf.ui.IConnectWizard interface.  This interface extends
IWizard.  Also, the containerFactoryName (in this case "org.my.client")
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:

   <extension
         point="org.eclipse.ecf.containerFactory">
      <containerFactory
            class="org.my.client.ContainerInstantiator"
            description="ECF Generic Client"
            name="org.my.client"
            </containerFactory>
   </extension>

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

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

And that's it.

To do IContainer creation and configuration via the registered wizard:

ConfigurationWizardDialog cwd = new ConfigurationWizardDialog(shell,
workbench);
cwd.open();
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,
workbench);
cwd.open();
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).

Thanks,

Scott













------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


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


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top