Developing Eclipse Plugins

This article presents a set of best practices for use when developing Eclipse plugins for application development environments built on the Eclipse platform. The general principles of plugin development outlined in this article can be applied to many other Eclipse-based development environments, in addition to the downloadable version. Several aspects of the Eclipse plugin development process are covered here, including the View versus Editor debate, the inside or outside choice, some standard widget toolkit (SWT) basics and the usefulness of the Eclipse Plugin Wizard. The advantages of using Eclipse for developing Eclipse plugins also are covered. The article also includes a walk-through of a simple application plugin with an eye toward reuse across multiple Eclipse application plugins.

In Eclipse, the two basic ways of presenting any type of information to the user are with a View or an Editor. Both Views and Editors allow the user to select certain actions to be performed by the plugin by single- or double-clicking on an item, by a right-click pop-up menu or by a top-level pull-down menu item.

The Editor class can do almost everything that the View class can do, plus a whole lot more. Allowing all this extra functionality comes at a price, however, in both system and code complexity. In general, the Editor class requires much more effort to develop than a View, so a certain amount of decision making must occur before embarking on an Editor implementation.

Views are sufficient when simply providing information to a user and allowing certain built-in capabilities is required. Users can input data to Views with relative ease usually by using other widgets in the SWT, such as tables and text boxes. But, what if you want more of a free-form interaction with the user? In addition, what if you want to have user inputs that are persistent across multiple launches of Eclipse?

A good general guideline to use in this debate is the issue of persistence. Although it is possible to retain data from a View in some kind of persistent repository, in most cases this requires some level of work to be done in a file or file-like context. If this is the case, it often is easier simply to implement an Editor instead.

The second most common consideration is the actual data being presented. If the user can select multiple data units and perform actions using them or against them on a one-at-a-time basis, it usually is easier to implement the operation or operations as a distinct View.

In this article, we implement a sample Eclipse plugin. This plugin has a simple goal: to provide generic application-level data to the user. This data is going to be represented as strings, although almost any data type could be substituted. The usual left-click, right-click and double-click actions are going to be enabled, but only double-clicking is modified as a reusable example for all other action implementations.

As there is no immediate need for a persistent resource and as there will be multiple instances of data to select on a one-at-a-time basis, the sample plugin capability is going to be implemented as a View, which we simply call the DataView.

When implementing either Views or Editors, another decision must be made. Should the data be presented to the user within the actual Eclipse environment or outside of it somehow? The SWT provides Form classes that allow you to externalize your application data if you choose.

Editors can be implemented either externally or internally, but external Editors lack easy access to the plugin itself. Surprisingly, existing vendor plugins provide exactly this kind of functionality. In most of these cases, this is chosen because of the loss of plugin access as vendors decide to lock out the user from certain levels of Eclipse functionality. In general, the proper choice for plugin Editors—notwithstanding the user debate over openness in tools—is to implement Editors internally in Eclipse. It simply doesn't make much sense to lose access to the rest of the plugin if you don't have to. Now, what about Views?

Similar to Editors, Views can be implemented either externally as a separate Form class or internally as a View with additional SWT widgets. There are no hard and fast rules here, but there are some basic guidelines to follow when dealing with this decision. In general, two things should be considered. First, can the View data be described as unique and discrete entities, with fields or operations specific to that particular data item? Second, are there always less than about nine of these items? If so, the View can be implemented as a View with a Table or perhaps a View with separate Tabs for each discrete unit.

If the actual number of instances of the data and the types of operations on that data is at all dynamic or unknown—for example, the developer does not know a priori exactly how many items there will be or exactly how many distinct operations to design or to allow for in the future—it probably is best to implement the View as an external Form class.

The sample plugin developed in this article is a simple 100-item implementation displaying data with only two distinct fields for each item, a name and a value. Although there are no predefined system requirements for more than nine multiple operations, there also are no explicit multiple operations defined. Therefore, you safely can assume that it will not require a great deal of them either—it is supposed to be simple after all. The DataView plugin therefore should be implemented as an internal View.