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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- Designing Electronics with Linux
- What's the tweeting protocol?
- Kernel Problem
2 hours 23 min ago
- BASH script to log IPs on public web server
6 hours 50 min ago
10 hours 26 min ago
- Reply to comment | Linux Journal
10 hours 58 min ago
- All the articles you talked
13 hours 22 min ago
- All the articles you talked
13 hours 25 min ago
- All the articles you talked
13 hours 26 min ago
17 hours 51 min ago
- Keeping track of IP address
19 hours 42 min ago
- Roll your own dynamic dns
1 day 55 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?