[news.eclipse.platform.rcp] Re: How parts communicate - best practice

[Diego Tognola <diego@xxxxxxxxxxx>]

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 ?).

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.
If in addition you run into problems with the control of behaviour, you may
consider the 'mediator pattern'.

Of course this should only occur for types of events which other components
could be interested in. Events such as the selection of a UI component
should first be dealt with by the UI component itself. It may do a refresh
or local logic, then optionally fire a 'public' event to the message bus.

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.

The reason I suggest this is that if you go down the path
of 'point-to-point' connections, you may end up with event firing sequences
that are too complicated to maintain or modify.

Hope that help,
Diego