Eclipse Workbench Selection and Adapters and why they are so important

As more and more people are diving into Eclipse in the Notes community one very important area of the Eclipse workbench that needs to be understood is the Eclipse Workbench Selection and then more importantly Adapters.  Understanding these two basic concepts will let your Eclipse view (or component) interact with other Eclipse parts with no “wiring”.  The workbench selection is a fixed pub/sub where your component will be notified any time another part changes its selection – a workbench window only has one selection at a time.  This allows your view part to show relative information to the new selection.  The Adapter pattern explained in the linked article explains how you can provide selection objects that can be adapted to other well known object types.  It also shows you how you can adapt an existing selectable object type to something else.

Many of the side bar components that work off of a currently selected email or document use this pattern.  This allows your side bar component to be able to respond to what is currently selected.

Adapters article on

4 thoughts on “Eclipse Workbench Selection and Adapters and why they are so important

  1. Pingback: Tweets that mention Eclipse Workbench Selection and Adapters and why they are so important » --

  2. The Java views don’t return the correct multi selection through the standard workbench selection. They only return about 25 documents, which can be increased by using a Notes.ini variable, e.g. to 5000 documents:

    IBM calls this solution “performance optimization”. 😉

    For all “normal” Eclipse viewparts, you can register a selection listener at the ISelectionProvider:

    For the Java views, because the ISelectionProvider does only return those 25 entries, you need to work with the “activeViewer”:

    So to develop a solution that works for all viewparts, you need to explicitely create a dependency on the CSIView’s plugin, otherwise you can’t access that “activeViewer”.

    That is a really bad design.

    I understand that it would slow down the performance to create an IStructuredSelection for e.g. 5000 documents on every selection change (because the CSI views does not have all that data in memory), but then the Eclipse framework should have been extended to get an universal extended selection object for large selections, e.g. something that produces the selection data on demand when a listener actually reads them.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.