Component Framework

By providing simple API for views and editors, also known as parts, the Component Framework permits existing parts to be nested and composed. The Component Framework API allows clients to instantiate parts inside arbitrary SWT composites, improves robustness and leak proofing by having a part communicate with local interfaces on its site rather than reaching to global objects, allows clients to extend the set of interfaces available from a site and provides a framework for clients to create their own reusable components using the same API available to views and editors. The Component Framework also allows for constructing and destructing a part with atomic operations and allows existing parts to use new site interfaces.

Image of NameViewNew view

This simple example provides a view that sets its name, title, tooltip, and image and demonstrates how to write an editor or view using the component framework. It shows the source using the component API. New parts can take arguments in their constructor and do not need to implement any particular interface or need to inherit from any particular base class.

/**
 * Sample view that sets its name, tooltip, image, and content description. The view
 * uses a custom image supplied by its plug-in.
 *
 * @since 3.1
 */
public class NameViewNew {
    /**
     * Component constructor. Do not invoke directly.
     */
    public NameViewNew(Composite parent, INameable name, IPluginImages images) {
        name.setName("Name View (New)");
        name.setContentDescription("content description");
        name.setTooltip("This is a tooltip");
        name.setImage(images.getImage("icons/sample.gif"));
       
        // Create some bogus view contents
        Label content = new Label(parent, SWT.NONE);
        content.setText("View contents go here");
    }
}

Notice that the arguments given to the view's constructor are already aware of their context. For example, the IPluginImages interface does not need to be told which plug-in the view belongs to. Similarly, the interfaces are resistant to leaks. In this example, the view's image is allocated and deallocated automatically by the INameable implementation, so the view itself doesn't need to implement a dispose method.

It is interesting to note that the API for views and editors is exactly the same. In other words, if we had chosen to register the NameViewNew class with the org.eclipse.ui.editors extension point, it could also be used as an editor without further modification.