Home » Eclipse Projects » Rich Client Platform (RCP) » Plugin-plugin object communication
| Plugin-plugin object communication [message #398261] |
Tue, 07 December 2004 12:26  |
Eclipse User |
|
|
|
I can't help kick the feeling that I'm not doing this the right way
-basically trying to hijack a gui based mechanism to pass my own objects.
But after looking on this site, googling, reading various Eclipse books, I
just haven't found the answer.
I want to send my own custom objects with their state information between
plugins. These objects and their state may be created from separate
threads running outside the SWT gui thread. In other words I want to
communicate plugin to plugin passing my own objects with their state
information.
A real life practical example would be the creation of a transaction
object that holds state information such as "Processed" or a dollar amount
-how can I pass this transaction object from each separate plugin to
separate plugin? E.g. a merchant plugin may require the transaction
object, and a bank plugin may require the transaction object.
So far, I've successfully run an example which sent a gui component event
from an application plugin perspective view (ProducerView) using a
TableView selection provider to a separate plugin view (ListeningView),
which received it no problem. Thinking about this, I decided to implement
my own ISelectionProvider and "fake" a selection event, passing my own
custom objects with their state information between plugins. I
successfully did this -so now I have the application perspective view
(ProducerView) that comes up, sets my SelectionProvider and then starts up
a thread which randomly changes one of my own custom objects by invoking
my SelectionProvider's setSelection method. This is successfully received
by the separate plugin view ListeningView. The problem? Well, two of
them:
i. I can't add more than one ISelectionProvider to a view(?). I.e. when
I'm in my ProducerView, I might want to add selection provider that is a
table viewer, and a non-gui selection provider (such as the one I
created). The last ISelectionProvider added appears to be the one used.
ii. When I add my own custom SelectionProvider, and my other separate
plugin view ListeningView correctly receives the event with the custom
object. However, if I try to apply that state information to that gui
view (i.e. using a simple label in that view) then I get an swt thread
error. I know this means the separate test thread invoked by the
ProducerView is not running in the swt thread, but would I want it to
anyway? Surely I'd want non-gui events to be created outside the gui
thread?
Which brings me around to thinking I'm approaching this all
incorrectly.... Is there a way to pass custom objects between plugin views
that doesn't involve the ISelectionProvider? And is "non-gui"?
thanks.
|
|
|
| Re: Plugin-plugin object communication [message #398876 is a reply to message #398261] |
Wed, 08 December 2004 04:12  |
| Eclipse User |
|
|
|
It sounds like you are 'hijacking' the GUI!
My suggested short answer is to fall back on traditional Model View
Controller pattern.
Have a controller per plugin that communicates with the controllers of
other plugins. Their communication can be any mechanism that suits.(*)
GUi elements within each plugin are called by and listened to by the
plugin's controller only.
This encapsulates plugin gui behviour and allows controller logic to be
seperatly JUnit'ed.
* : my controller communications 'mechanism' could not be simpler. Each
controller is accessed via the plugin singleton
MyPlugin.getDefault().getController() and then direct method calls made.
This means that client plugins are depedendent on (ie. have static
knowledge of) the plugins they call but that's fine by my architecture.
If you need more a dynamic approach use a extension point to define
listeners for each controller and then publish your own controller events.
Mike E.
Nigel wrote:
> I can't help kick the feeling that I'm not doing this the right way
> -basically trying to hijack a gui based mechanism to pass my own
> objects. But after looking on this site, googling, reading various
> Eclipse books, I just haven't found the answer.
>
> I want to send my own custom objects with their state information
> between plugins. These objects and their state may be created from
> separate threads running outside the SWT gui thread. In other words I
> want to communicate plugin to plugin passing my own objects with their
> state information.
>
> A real life practical example would be the creation of a transaction
> object that holds state information such as "Processed" or a dollar
> amount -how can I pass this transaction object from each separate plugin
> to separate plugin? E.g. a merchant plugin may require the transaction
> object, and a bank plugin may require the transaction object.
>
> So far, I've successfully run an example which sent a gui component
> event from an application plugin perspective view (ProducerView) using a
> TableView selection provider to a separate plugin view (ListeningView),
> which received it no problem. Thinking about this, I decided to
> implement my own ISelectionProvider and "fake" a selection event,
> passing my own custom objects with their state information between
> plugins. I successfully did this -so now I have the application
> perspective view (ProducerView) that comes up, sets my SelectionProvider
> and then starts up a thread which randomly changes one of my own custom
> objects by invoking my SelectionProvider's setSelection method. This is
> successfully received by the separate plugin view ListeningView. The
> problem? Well, two of them:
>
> i. I can't add more than one ISelectionProvider to a view(?). I.e. when
> I'm in my ProducerView, I might want to add selection provider that is a
> table viewer, and a non-gui selection provider (such as the one I
> created). The last ISelectionProvider added appears to be the one used.
>
> ii. When I add my own custom SelectionProvider, and my other separate
> plugin view ListeningView correctly receives the event with the custom
> object. However, if I try to apply that state information to that gui
> view (i.e. using a simple label in that view) then I get an swt thread
> error. I know this means the separate test thread invoked by the
> ProducerView is not running in the swt thread, but would I want it to
> anyway? Surely I'd want non-gui events to be created outside the gui
> thread?
>
> Which brings me around to thinking I'm approaching this all
> incorrectly.... Is there a way to pass custom objects between plugin
> views that doesn't involve the ISelectionProvider? And is "non-gui"?
>
> thanks.
>
--
Mike Evans
Incremental Ltd.
www.incremental.eu.com
|
|
| | | |
| thanks Mike -I did it [message #398892 is a reply to message #398876] |
Wed, 08 December 2004 09:53 |
| Eclipse User |
|
|
|
Mike:
first, thanks so much for the reply - you put me on the right path!
I worked out how to do it -as you posted, I created a static controller
class in a perspective plugin. Then I simply called that controller using
the singleton call from a separate plugin..... Easy as it so happens -for
some reason I assumed the rcp would have some sort of event channel it had
to go through. I think I was inventing complications.
Regardless, it worked, and thanks again for your help.
Nigel
Mike Evans wrote:
> It sounds like you are 'hijacking' the GUI!
> My suggested short answer is to fall back on traditional Model View
> Controller pattern.
> Have a controller per plugin that communicates with the controllers of
> other plugins. Their communication can be any mechanism that suits.(*)
> GUi elements within each plugin are called by and listened to by the
> plugin's controller only.
> This encapsulates plugin gui behviour and allows controller logic to be
> seperatly JUnit'ed.
> * : my controller communications 'mechanism' could not be simpler. Each
> controller is accessed via the plugin singleton
> MyPlugin.getDefault().getController() and then direct method calls made.
> This means that client plugins are depedendent on (ie. have static
> knowledge of) the plugins they call but that's fine by my architecture.
> If you need more a dynamic approach use a extension point to define
> listeners for each controller and then publish your own controller events.
> Mike E.
> Nigel wrote:
>> I can't help kick the feeling that I'm not doing this the right way
>> -basically trying to hijack a gui based mechanism to pass my own
>> objects. But after looking on this site, googling, reading various
>> Eclipse books, I just haven't found the answer.
>>
>> I want to send my own custom objects with their state information
>> between plugins. These objects and their state may be created from
>> separate threads running outside the SWT gui thread. In other words I
>> want to communicate plugin to plugin passing my own objects with their
>> state information.
>>
>> A real life practical example would be the creation of a transaction
>> object that holds state information such as "Processed" or a dollar
>> amount -how can I pass this transaction object from each separate plugin
>> to separate plugin? E.g. a merchant plugin may require the transaction
>> object, and a bank plugin may require the transaction object.
>>
>> So far, I've successfully run an example which sent a gui component
>> event from an application plugin perspective view (ProducerView) using a
>> TableView selection provider to a separate plugin view (ListeningView),
>> which received it no problem. Thinking about this, I decided to
>> implement my own ISelectionProvider and "fake" a selection event,
>> passing my own custom objects with their state information between
>> plugins. I successfully did this -so now I have the application
>> perspective view (ProducerView) that comes up, sets my SelectionProvider
>> and then starts up a thread which randomly changes one of my own custom
>> objects by invoking my SelectionProvider's setSelection method. This is
>> successfully received by the separate plugin view ListeningView. The
>> problem? Well, two of them:
>>
>> i. I can't add more than one ISelectionProvider to a view(?). I.e. when
>> I'm in my ProducerView, I might want to add selection provider that is a
>> table viewer, and a non-gui selection provider (such as the one I
>> created). The last ISelectionProvider added appears to be the one used.
>>
>> ii. When I add my own custom SelectionProvider, and my other separate
>> plugin view ListeningView correctly receives the event with the custom
>> object. However, if I try to apply that state information to that gui
>> view (i.e. using a simple label in that view) then I get an swt thread
>> error. I know this means the separate test thread invoked by the
>> ProducerView is not running in the swt thread, but would I want it to
>> anyway? Surely I'd want non-gui events to be created outside the gui
>> thread?
>>
>> Which brings me around to thinking I'm approaching this all
>> incorrectly.... Is there a way to pass custom objects between plugin
>> views that doesn't involve the ISelectionProvider? And is "non-gui"?
>>
>> thanks.
>>
|
|
|
| You beat me to it..... [message #398893 is a reply to message #398891] |
Wed, 08 December 2004 09:56 |
| Eclipse User |
|
|
|
Just as I posted that last post of mine, I refreshed and saw your messages
- once again, thanks for help -and the example. As I put in my last
message I was thinking it was far more complicated.
Wishing you a happy and prosperous Holiday season,
Nigel
> Mike Evans wrote:
>> The straight answer is explicit code.
>>
>> The de-facto Eclipse/RCP singleton pattern is :
>>
>> public class MyPlugin extends AbstractUIPlugin {
>>
>> // singleton instance
>> private static MyPlugin _instance = null;
>>
>> public static MyPlugin getDefault() {
>> return _instance;
>> }
>>
>> public MarketingPlugin() {
>> super();
>> }
>>
>> public void start( BundleContext context ) throws Exception {
>> super.start( context );
>> _instance = this;
>> }
>>
>> public void stop( BundleContext context ) throws Exception {
>> _instance = null
>> super.stop( context );
>> }
>>
>>
>> This takes advantage that the platform guarantees to only start a single
>> instance of a plugin at any one time. (Ok 'guarantee' is a strong word
>> and I do not know about all the relatively new OSGI cleverness - but if
>> you are not explicitly fiddling with bundle activations I believe this
>> to be true).
>>
>> Now that you have your singelton you can add any number of fields with
>> public accessors.
>>
>> Mike E.
>>
>> Nigel wrote:
>>
>>> OK, stupid hat=on
>>>
>>> The problem I have (and I honestly have been trying to read through
>>> and research on the web) is that I don't see any examples of this -and
>>> an example is worth a lot! I see how any plugin can access a library
>>> or another plugins classes, but I don't see how they communicate with
>>> another plugin's "instance". So creating a controller within a plugin
>>> is fine, but how do I communicate with that plugin that contains that
>>> controller from another separate plugin? It's the "...that
>>> communicates with the controllers of other plugins..." bit I'm having
>>> difficulty with!
>>>
>>> Frustratingly, I know I must be missing something. Heck, I'm not
>>> usually this slow. Dare I say, stupid hat=off?
>>>
>>> thanks
>>>
>>>
>>> Mike Evans wrote:
>>>
>>>> It sounds like you are 'hijacking' the GUI!
>>>> My suggested short answer is to fall back on traditional Model View
>>>> Controller pattern.
>>>> Have a controller per plugin that communicates with the controllers
>>>> of other plugins. Their communication can be any mechanism that
>>>> suits.(*)
>>>> GUi elements within each plugin are called by and listened to by the
>>>> plugin's controller only.
>>>> This encapsulates plugin gui behviour and allows controller logic to
>>>> be seperatly JUnit'ed.
>>>
>>>
>>>
>>>> * : my controller communications 'mechanism' could not be simpler.
>>>> Each controller is accessed via the plugin singleton
>>>> MyPlugin.getDefault().getController() and then direct method calls
>>>> made. This means that client plugins are depedendent on (ie. have
>>>> static knowledge of) the plugins they call but that's fine by my
>>>> architecture. If you need more a dynamic approach use a extension
>>>> point to define listeners for each controller and then publish your
>>>> own controller events.
>>>
>>>
>>>
>>>> Mike E.
>>>
>>>
>>>
>>>
>>
|
|
|
Goto Forum:
Current Time: Sat Nov 08 21:04:19 EST 2025
Powered by FUDForum. Page generated in 0.05123 seconds |
Home