Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Thoughts about ECF connection ui 
I think this is a good idea, but providing a default implementation
that can be easily extended would be good.

I don't like the current situation where I have to describe what the
UI looks like in the container factory extension point.

Also, what facility should provide auto-connect at startup? I
personally think that auto-connect should have no dependencies on UI
or wizards in particular (but a wizard should be able to specify that
auto-connect should be used. (Note: I have no idea how it currently
works, maybe it already is as I described?)

I think it should follow the tradition of IConfigurationWizard,
INewWizard, IImportWizard, IExportWizard by extending IWizard, not
IWizardPage.

On 11/8/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Folks,

I'm contemplating creating a new extension point for the ECF ui plugin
called "org.eclipse.ecf.ui.connectConfigurationWizards".  This extension
point would allow provider plugins (or other plugins) to define wizards
UIs for collecting information necessary to call

IContainer.connect(ID,IConnectContext)

The extension would be required to provide an implementation class for
this new interface:

package:  org.eclipse.ecf.ui.IConnectWizard

public interface IConnectWizard extends IWizard {

     public void init(IWorkbench workbench, IContainer containerToConnect);

}

Then, in a new ECF connect dialog it would be possible to select the
desired provider, and get extensions in registry implementing this
extension point (for matching types/provider names of IContainers).
When found, the above init method would be called with the
selected/created container instance, and the implementation would define
wizard pages, appropriate input widgets, get appropriate info (for ID
construction) from UI and call the IContainer.connect method (and
handle/display errors, etc).

What do people think about this approach?  Any comments?  It would allow
us/others to decouple the connect UI from the provider implementation,
although it *could* be defined by the provider as well (if the provider
needs/wants to have a particular connect dialog that collects certain
information from user for making a connection).  We could have the
existing ECF connect dialog as a default, so that if a given provider
can/wants to use that (where the resulting params for connect are a
String or URI...for ID...and a String password).

In some ways, this is intended to be similar to the Team UI extension
point org.eclipse.team.ui.configurationWizards...which are used to
collect configuration information (e.g. hostname, username, port,
password, protocol, etc) for connection to team providers (like CVS).

One other thought/question that I had:

Should IConnectWizard instead be IConnectWizardPage (extending IWizardPage)?

Let me know what you think.

Scott


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

Back to the top