• The pieces of a plug-in: views, actions, and editors
• Perspectives: how Eclipse sees itself
• Features and what they do

The Pieces of a Plug-In

In order to understand the concept of a plug-in, you should understand the various pieces that make up a plug-in. It's important to know that these pieces are optional--no one plug-in needs all of these pieces. In fact, most plug-ins use only a subset of the available plug-in components. Figure 1 shows views, actions, and editors, which are some of the more common aspects of a plug-in.

Figure 1: The three most common parts of a plug-in are views, actions, and editors.

A view is a customized list of objects. One of the primary views is the "navigator" view, which is usually used to access all the objects in a coherent manner. For example, in the PDT, the view includes the Java source and classes, the required .jar files, the icons and HTML help files, and the XML files that configure the plug-in. By using the navigator view, you can move from one object to another.

Each view has actions. These actions appear in a toolbar at the top of the view. However, the objects in the view (especially the navigator view) also have context-specific actions accessible through a pop-up menu. It is up to the plug-in designer to populate these menus as appropriate. This includes identifying which actions make sense when multiple objects are selected. Actions can be anything from adding or deleting an object to changing an object's properties. But the fundamental option for an IDE, the one service we need the IDE to provide, is editing.

And that's where editors come in. Typically, an object-aware editor is invoked whenever you ask to edit an object. There are many variations of the simple editor. Read-only editors are possible, though obviously of limited usefulness. Brain-dead generic text editors can be used. And while these editors don't do much for productivity, they at least handle those files for which we have yet to design the special-purpose editors. And those special purpose editors are the cream of the crop. With Eclipse, the bulk of the special purpose editing is supposed to be done by the LPEX editors. So far, I think they do an adequate job. I'll follow up that subjective opinion with more facts in a later article.

There are other optional parts to a plug-in as well. A wizard is probably the one you are most likely to use. Wizards allow you to walk a user through the configuration of an action step by step using dialogs. This is most effective for things like "New" actions, where the user is creating a new object. Also, you can create preferences pages that allow the user to define global values that will persist from one session to the next and that change the way the plug-in operates. Finally, for objects with complex properties, you can specify property pages that function a lot like wizards to allow you to dynamically update those properties without having to write a lot of customized UI programming.

It's important to note that some "standard" views come along with the IDE. For example, the tasks view and the properties view are always available (I'll explain more about that in the Perspectives section) and should probably operate the same way in your plug-in as they do in other plug-ins. This sort of consistency from one view to the next is a way to reduce the learning curve for your plug-in. Your actions should also follow consistent naming conventions--"Open" rather than "Edit," for example, or "Browse" for read-only access. (National language support is also present, but it's a little too much to fit into this introductory article.)

Perspectives

So now we have all these pieces to plug in. What exactly do we plug them in to? Good question...the answer is "a perspective." And, more often than not, the answer is "an existing perspective."

So what is a perspective? In simplest terms, a perspective is a collection of views. The perspective identifies the views that are available to the user. Some perspectives are shipped with the product or with features (see the Features section below). Perspectives have a default layout that is used the first time the perspective is opened (you can also reset a perspective back to its default layout). When a plug-in adds a new view, it adds it to the general population of views, but it may also add it specifically to the default layout of an existing perspective. This requires that the plug-in designer know the layout of the perspective and that the layout is fairly static. Not only that, but adding to the default layout may not do much good, since one of the primary features of Eclipse is the ability for users to customize the layout of their perspectives and even to create new ones of their own.

The following figures show how easy it is to configure your own perspective.

Figure 2: Adding a view to a perspective is as easy as selecting it from the pulldown menu.

By using the Window/ShowView option, you can add any of the available views to your current perspective. It will add the view to a default location on the page. However, you aren't limited to that location.

Figure 3: Moving a view is as easy as dragging and dropping it.

As you can see in Figure 3, you can just drag and drop the view from one pane to another. You can also resize--or even split--the panes. And once you've arranged your layout to your liking, you can save it as your own new, custom perspective.

The perspective also filters the objects viewed. For example, you might have four projects. When Eclipse comes up, it normally shows all of those projects in the default perspective, but you can easily open a new window by right-clicking on a project and selecting the Open in New Window option. A new window will open up that shows only that particular project. The same perspective is being used, but now it includes only objects for the specified project.

So, with views and perspectives, it is easy to imagine how you might be able to build what amounts to your own IDE by simply combining the appropriate panes on your display. As more and more third-party plug-ins become available, you'll find that you can add a search engine in one pane and a COBOL editor in another. There are only two drawbacks to this scheme:

1) The third-party options don't always work and play well with one another. Sometimes, you won't be able to add an object to a project because it's not the right type. While I guess I can understand the reasoning, I'd still like the ability to combine objects the way I want to, not the way the developers see fit. I think this will become even more of an issue with cross-platform development projects.

2) The second issue is a problem more for consultants than for full-time employees. Consultants will probably become comfortable with their own perspectives and may find themselves having some difficulties at different shops, which may not have the same plug-ins installed. This is not unlike the issue of customizing your keyboard. You do it at your peril.

Features

Finally, there's the concept of a feature. A feature is a set of related plug-ins that can be thought of as loosely analogous to a "product." While not particularly remarkable in its own right, the feature concept has been taken to a very nifty level by Eclipse. Features can identify "update URLs," which can then be accessed to find the latest and greatest version of the feature. When a newer version becomes available, the Update Manager perspective can be used to download the new version and install it. Not quite as automatic as the Windows Update, but still pretty nice.

So How Hard Is It?

To be honest, it's a little daunting to create plug-ins. Because the PDT comes with a really robust set of wizards, it's relatively easy to create a simple plug-in. However, mastering the intricacies of a truly useful plug-in is going to take more than just a couple of spare weekends.

Even the simplest questions--such as whether to create your own perspective, and if so, how to do that--are quite complicated. I've spent days and days slogging through the documentation, and there really isn't a lot out there for the neophyte. You'll probably have to do like I did and use the old tried and true method of starting with a working example. Then, change things and see what you break. One of the problems is that the debugging capabilities of the JDT aren't quite up to snuff with VAJ (in particular, it doesn't handle unexpected exceptions very well), so it's a little harder to learn, especially in those initial stages when you don't know enough to know what you need to learn.

Conclusions

Ah, the conclusions section of the article. Well, my conclusion is that the framework for plug-ins is very robust and flexible. This is often programmer doublespeak for "very complicated," and in this case, it's true. The APIs for designing Eclipse plug-ins are complex and often hard to understand. Creating a plug-in is not for the faint of heart, and my guess is that any of us who tries is going to spend a lot of time on the "error" side of "trial and error."

I think the amount of flexibility available will make it easy to over-engineer our first attempts, but eventually I think a sort of "standard" for plug-ins will begin to develop. Until then, those on the bleeding edge of plug-in development are likely to get very bloody indeed.

But the more appropriate issue is whether you'll need to create plug-ins at all. You may want to look at some of the existing plug-ins to see what makes sense. In the long run, you may be better off simply downloading a plug-in or two and then configuring your own perspective. This is where the product will shine. Because you'll be able to add new plug-ins whenever they become available, it's unlikely that you will outgrow Eclipse for some time. And as the industry evolves and more new technologies emerge, Eclipse will be able to keep up with them.

So, my conclusion? As a developer, you're going to have to learn this tool. Will software vendors need to write their own plug-ins? That's going to depend very much on consistency and market acceptance.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..