Over a million developers have joined DZone.

Perspective Layouts - Programmatic vs Declarative

· Java Zone

Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems, brought to you in partnership with AppDynamics.

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.

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.


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.

From http://rcpquickstart.com/

The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.


The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}