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 Eclipse.org.

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 » Balfes.net -- Topsy.com

  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:
    WMCSELECTION_MAXDOCUMENTS=5000

    IBM calls this solution “performance optimization”. 😉

    For all “normal” Eclipse viewparts, you can register a selection listener at the ISelectionProvider:
    viewpart.getViewSite().getSelectionProvider()

    For the Java views, because the ISelectionProvider does only return those 25 entries, you need to work with the “activeViewer”:
    csiViewPart.getActiveViewer().addSelectionListener()

    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.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s