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