Bestpractice for connecting non-ui with ui plugin [message #291731] |
Thu, 22 September 2005 10:28 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: eclipse.bettsockentraeger.de
Hello,
currently I'm developing a Plugin which consists of a backend non-ui
plugin and a front-end which is represented as a ui-plugin. The
ui-plugin (I'm going to refer to this as UI from here on) is dependent
on the non-UI (refered to as NONUI from here on) plugin.
The interaction of the UI with the NONUI plugin is basically done
through a set of well defined interfaces.
So my question is, what is the best practice to connect the two plugins?
Here are the options I'm seeing currently:
1. Develope an extension point in NONUI that will provide an interface
which enables it to inject the needed interface into the UI plugins.
2. Develope an extension point in UI that will enable the NONUI plugin
to inject the interfaces into the UI plugin.
3. Simply create a static method in NONUI Pluginclass and export it to
the UI Plugin which will call this method to obtain the needed interfaces.
The following pros and cons come to mind
1. PRO: Enables other UI Plugins to specify the same extension point and
use the same interfaces to do their job.
CON: I need to create an additional interface that the UI Plugin has to
implement in order to inject the needed interfaces.
2. CON: NONUI depends on UI which is definitly not what I want so this
eliminates this option!
3. CON: Static coupling of UI to NONUI although they allready are
coupled by the dependence of UI to NONUI.
PRO: Easy to implement no need to create any special injector class,
interface.
So what is the best option? I'm favouring 1 at the moment. Are there
other ways of achiving the same thing?
And to 1. what is the best way of providing the Interface that has to be
implemented for the extension point. Exporting the package containing
the interface or providing a jar that has to be on the runtime classpath
of the UI PLugin?
Thanks for any help
Stefan
|
|
|
Re: Bestpractice for connecting non-ui with ui plugin [message #291752 is a reply to message #291731] |
Thu, 22 September 2005 13:37 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: Michael_Valenta.oti.com
Stefan,
From your description, it seems that you have a particular case in mind but
without knowing the specifics I can only talk in generalities. In general, I
think approach 3 is used most often (but the UI can reference any API in the
NONUI plugin and not just static methods) and approach 1 is used in
situations when operations deep in the bowels of the NONUI need to obtain
information from the user (Point 2 doesn't make sense to me since UI depends
on NONUI so NONUI could never implement a UI extension point).
Just to give a concrete example, the CVS plugin is divided into CORE and UI
pieces. The UI plugin uses classes from the CORE plugin to issue CVS
commands to the server but will prompt the user for command input and
display results. There are definitely some static methods and singletons
involved but a lot of it is done by UI instantiating classes defined in CORE
as well. However, there are several cases where the CORE needs access to the
UI at a very low level. One of those places is dealing with authentication
failues. When a connection fails, the CORE plugin loads an authenticator
extension point in order to obtain a new password for the server. The UI
plugs in the authenticator which prompts the user in a dialog. I must warn
you that getting these callbacks to work properly is not easy and should
only be done if there are no alternatives.
Michael
"Stefan Langer" <eclipse@bettsockentraeger.de> wrote in message
news:dgu0u9$ieu$1@news.eclipse.org...
> Hello,
>
> currently I'm developing a Plugin which consists of a backend non-ui
> plugin and a front-end which is represented as a ui-plugin. The ui-plugin
> (I'm going to refer to this as UI from here on) is dependent on the non-UI
> (refered to as NONUI from here on) plugin.
> The interaction of the UI with the NONUI plugin is basically done through
> a set of well defined interfaces.
> So my question is, what is the best practice to connect the two plugins?
> Here are the options I'm seeing currently:
>
> 1. Develope an extension point in NONUI that will provide an interface
> which enables it to inject the needed interface into the UI plugins.
>
> 2. Develope an extension point in UI that will enable the NONUI plugin to
> inject the interfaces into the UI plugin.
>
> 3. Simply create a static method in NONUI Pluginclass and export it to the
> UI Plugin which will call this method to obtain the needed interfaces.
>
> The following pros and cons come to mind
> 1. PRO: Enables other UI Plugins to specify the same extension point and
> use the same interfaces to do their job.
> CON: I need to create an additional interface that the UI Plugin has to
> implement in order to inject the needed interfaces.
>
> 2. CON: NONUI depends on UI which is definitly not what I want so this
> eliminates this option!
>
> 3. CON: Static coupling of UI to NONUI although they allready are coupled
> by the dependence of UI to NONUI.
> PRO: Easy to implement no need to create any special injector class,
> interface.
>
>
> So what is the best option? I'm favouring 1 at the moment. Are there other
> ways of achiving the same thing?
> And to 1. what is the best way of providing the Interface that has to be
> implemented for the extension point. Exporting the package containing the
> interface or providing a jar that has to be on the runtime classpath of
> the UI PLugin?
>
> Thanks for any help
>
> Stefan
|
|
|
Re: Bestpractice for connecting non-ui with ui plugin [message #292095 is a reply to message #291731] |
Thu, 29 September 2005 12:55 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Stefan Langer wrote:
> Hello,
>
> currently I'm developing a Plugin which consists of a backend non-ui
> plugin and a front-end which is represented as a ui-plugin. The
> ui-plugin (I'm going to refer to this as UI from here on) is dependent
> on the non-UI (refered to as NONUI from here on) plugin.
> The interaction of the UI with the NONUI plugin is basically done
> through a set of well defined interfaces.
> So my question is, what is the best practice to connect the two plugins?
> Here are the options I'm seeing currently:
>
> 1. Develope an extension point in NONUI that will provide an interface
> which enables it to inject the needed interface into the UI plugins.
>
> 2. Develope an extension point in UI that will enable the NONUI plugin
> to inject the interfaces into the UI plugin.
>
> 3. Simply create a static method in NONUI Pluginclass and export it to
> the UI Plugin which will call this method to obtain the needed interfaces.
>
> The following pros and cons come to mind
> 1. PRO: Enables other UI Plugins to specify the same extension point and
> use the same interfaces to do their job.
> CON: I need to create an additional interface that the UI Plugin has to
> implement in order to inject the needed interfaces.
>
> 2. CON: NONUI depends on UI which is definitly not what I want so this
> eliminates this option!
>
> 3. CON: Static coupling of UI to NONUI although they allready are
> coupled by the dependence of UI to NONUI.
> PRO: Easy to implement no need to create any special injector class,
> interface.
>
>
> So what is the best option? I'm favouring 1 at the moment. Are there
> other ways of achiving the same thing?
> And to 1. what is the best way of providing the Interface that has to be
> implemented for the extension point. Exporting the package containing
> the interface or providing a jar that has to be on the runtime classpath
> of the UI PLugin?
>
> Thanks for any help
>
> Stefan
I think for legacy reasons 3 is the most used. Its what I use. It was
around before all the osgi stuff. I think it may have some problems if
you try to create a non-singleton NONUI plugin. I think somehow it
needs updating to fit in with osgi. But for now it works.
CL
|
|
|
Powered by
FUDForum. Page generated in 0.03130 seconds