One issue that developers new to RCP face is whether to add UI elements programmatically or declaratively. In my experience, most initially choose the programmatic approach because it seems more familiar. You know, why mess with extension points when you can just code it up and be done with it.
But it’s almost always better to do things declaratively through extension points, the main reason being that doing so allows you leverage the power of RCP as a modular user interface framework. To illustrate this, let’s look at our options for laying out perspectives.
Programmatic Layout = Centralized / Hard Coded
Here is the simplest code needed to add a view to a perspective programmatically. To do so, we implement the IPerspectiveFactory interface and add a view using its string id.
public class MyPerspectiveFactory implements IPerspectiveFactory {
public void createInitialLayout(IPageLayout layout) {
layout.addView(MyView.ID, IPageLayout.BOTTOM, 0.5f, layout.getEditorArea());
}
}
The problem here is that we’ve coupled our perspective to the view being added. This view may exist in the same plug-in as the perspective, but often it does not. If the view is in a different plug-in, we have to declare a dependency on that plug-in just to add the view. It’s possible to reduce the coupling somewhat by replacing MyView.ID with the actual string id itself, but hidden dependencies based on string equivalency are arguably even more smelly.
In the end, a programmatic perspective layout results in a hard-coded and centralized architecture looking like this.
Declarative Layout = Decentralized / Modular
The declarative approach based on extension points resolves these issues. To layout a perspective declaratively we extend the org.eclipse.ui.perspectiveExtensions extension point.
<extension
point="org.eclipse.ui.perspectiveExtensions">
<perspectiveExtension
targetID="com.mycompany.myperspective">
<view
id="com.mycompany.myview"
minimized="false"
ratio="0.5"
relationship="left"
relative="org.eclipse.ui.editorss">
</view>
</perspectiveExtension>
</extension>
Using this approach, each plug-in adds the views that it knows about, resulting in a decentralized architecture where the plug-ins containing the views are now in control.
Note that we have not eliminated all coupling, as the perspective extensions still need to refer to the perspective by its string id, but this is not as bad as it sounds. Perspectives are much more static than views – you typically define them and make few changes afterwards. Views, on the other hand are often moved from one plug-in to another or have their purpose (and potentially their id) redefined. Decentralizing control allows you to make these kinds of changes without breaking the perspective layout.
Conclusion
Adding UI elements declaratively is definitely the way to go. It gives you much more flexibility (e.g. you can add views to perspectives you didn’t create) and also allows you to leverage the modular nature of the framework.
Sure, there will always be cases where a declarative approach cannot be taken, particularly when some part of an API is not yet surfaced in the related extension point. But in the absence of such a need, I urge RCP developers to always turn first to the extension point mechanisms and fall back to programmatic approaches as a last resort. As your application evolves over time, you’ll really come to enjoy the flexibility and increased reusability that a declarative approach makes possible.
Patrick on the RCP Panel at EclipseCon