[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform.rcp] Re: How parts communicate - best practice 
Hi Diego!

Obviously there are many approaches the best you will have to choose from.
I've ended up creating a 'message bus' singleton, similar to JMS in
enterprise applications. (I find it exciting how all these JEE problems
even occur in a standalone application - so why not use the same
patterns ?).


Great analogy, you are thinking of jms messaging queues?

You essentially have a singelton that is registered with the application's
main plugin. It maintains lists of listeners of different type and offers
the standard add/remove listener and fire event functionality. This allows
for a 'loose coupling' of event producers and consumers. The firing party
doesn't care if and how by the event is consumed by.
>
I thougt about listeners, too. But where to place them? The data model is a very central place, but that's no loose coupling.

In your case, the selection of a new 'current account' would definitely be a
candidate for a message fired via the message bus. The event would then
either include a reference to the new account and be dealt with by the
other perspective. Alternatively, the event would only notify listeners
that there was a change and the perspective would get the new account from
a centralised data model, if this is the approach you take.

Does the rcp include such message bus? Other frameworks use similar mechanisms and promote events. Often integer types (extendable) are used to identify such events.
My main target is loose coupling and robust messaging. How can i avoid, that event A in plugin 1 does not confict with event A in plugin B?
Are (rcp-) commands the right way for messaging?

Markus