Eclipse RCP: A Platform for Building Platformsby Wayne Beaton
Technology has a definite cycle. After a decade of dominance by thin clients, rich-client technology is making a comeback. Numerous organizations are building their applications as rich clients and many of them are basing their applications on the Eclipse Rich Client Platform (RCP). The term "rich client" implies first that the application provides the user with a rich experience; second, it implies that the application is a client for some server. While it is not necessarily the case that a rich client has a corresponding server component, this is often the case.
Rich clients are in many ways comparable to fat clients. Both provide the user with a native desktop experience, presenting information and functionality for the user that is difficult, undesirable, or impossible to deliver using thin-client technology. However, rich clients provide so much more. Where fat clients tend to be large monolithic applications that are difficult to deploy and update, rich clients are lighter weight and based on a component model that makes them relatively easy to deploy and update. Historically, fat clients have been built to be platform specific; today's rich-client technologies expose the power of the underlying platform, but hide away the details of that platform, allowing the developer to focus on the task rather than idiosyncratic details of any particular platform.
Rich clients also tend to be more scalable than fat clients. Traditionally, fat clients connect directly to a database. This limits the environments where fat clients can run (firewalls may restrict connections from the fat client to the database) and the scalability of the application (the total number of connections from the clients to the server) may be limited by the database. Rich clients tend to leverage application servers that are responsible for making connections to the database. This sort of configuration is very flexible (firewall friendly) and is highly scalable. Of course, there is nothing in the technology that necessarily limits fat clients from communicating with an application server, it's just that in the heyday of fat-client technology, application servers didn't exist like they do now.
There are no rules that state that a rich-client application must be a client for some corresponding server. Many organizations leveraging rich-client technology are building robust, extendable, updatable, localized, standalone applications. Similarly, while rich clients tend to leverage application servers, there is no rule or technology limitation that forces this to be true. There is no reason why a rich-client application cannot access a database directly.
Rich-client technology represents a marriage of the strengths of fat-client and thin-client technology: rich user experience, highly scalable, platform-independent, and fairly easy to deploy and update.
The Eclipse RCP is the functionality that lies at the core of the Eclipse platform. When most people think of Eclipse, they think of the Java Integrated Development Environment (IDE). If you strip away the parts of Eclipse that make it an IDE, you're left with a core that provides the fundamental workbench functionality, including support for movable and stackable window components (editors and views), menus, tool bars, push buttons, tables, trees, and much more. This core functionality is Eclipse RCP.
Eclipse RCP offers the application developer:
- A consistent and native look and feel for applications and features
- Common application services such as window management, update management, help, and selection management
- A native look and feel, leveraging real platform widgets on Windows, Mac OS X, Linux, Solaris, HP-UX, AIX, and embedded devices
- A standardized component model
- Pervasive extensibility
- Integrated update mechanism
- First-class development tools (the Eclipse Software Development Kit (SDK) is a world-class software development environment)
Although it is actually an inappropriate use of the term, Eclipse RCP can be considered middleware for building rich-client applications. It provides the infrastructure that your application needs, which allows developers to focus on core application functionality not the plumbing. Don't reinvent the wheel: use Eclipse RCP.
The Eclipse RCP is composed of numerous components, and each component contributes to some part of the overall functionality of the environment. In fact, almost all of the Eclipse RCP is made of components; every part of RCP, with the exception of a small amount of bootstrap code is a component. Components are more commonly known as plug-ins in Eclipse circles (or bundles in OSGi terminology). The term "plug-in" implies that the functionality contained within the component is somehow second class, or an add-on to built-in functionality. This is not the case; Eclipse RCP treats all plug-ins as equals and there is no explicit notion of built-in versus custom. The plug-ins that you create to contribute your application's behavior are run alongside those that make up Eclipse RCP.
A natural way to start the development of a rich-client application is to begin with a single plug-in. Within a single plug-in, you can define the entire user interface, business logic, and object model for your application. Creating a new Eclipse Rich Client Platform application is as easy as selecting menu item File>New>Project..., choosing to create a new Plug-in Project, and following steps presented by the resulting wizard. On the Content page of the wizard, be sure to answer "Yes" to the question, "Would you like to create a rich client application?" The Templates page of the wizard is shown in Figure 1; here we choose to create an RCP application with a view.
Figure 1. The Templates page from the New Plug-in Project wizard
This will create a new plug-in that contains the parts necessary for an RCP application including configuration of the workbench (menu bar and tool bar) and a single view containing a table (see Figure 2).
Figure 2. The wizard creates a fully functional RCP application
The wizard generates the following classes:
- The generated
Applicationclass contains a single method,
run(Object args)that is responsible for running the application (oddly enough). This method bootstraps and opens the workbench window. When this method exits, the application shuts down.
ApplicationActionBarAdvisorclass is responsible for building the menu bar, tool bar, and status line. The generated class creates a menu bar with a single File menu with an Exit item. You can add the
fillCoolBar(ICoolBarManager coolBar)method to add a toolbar to your workbench window. Similarly, you can add the
fillStatusLine(IStatusLineManager statusLine)method to add a status line to the workbench window
ApplicationWorkbenchAdvisorclass provides numerous hooks into the application life cycle. You can, for example, add methods that are invoked when the application is started or shutdown. The generated implementation doesn't do very much other than specify the initial perspective presented to the user.
- Like the
ApplicationWorkbenchWindowAdvisorclass provides hooks into the workbench life cycle. You can add methods that are invoked when a workbench window is created, opened, restored, or closed. The generated implementation provides a
preWindowOpen()method that sets the initial size and title of the window, as well as the visibility of the tool bar and status line (both are not visible).
- The Eclipse SDK provides numerous perspectives. The generated application includes one; you can specify additional perspectives as required. The generated perspective hides the editor area (i.e., no editors will be visible in the perspective) and adds the view generated by the wizard. The perspective is set to be fixed: its views are rendered without the familiar title bars and cannot be moved. By changing the setting from
true(and adding a few more views to your application) the user can customize the position of the views to his heart's content.
- The generated
Viewclass contains a table with a handful of hardcoded entries. This is where you can render the appearance of your application. If a table is what you need, you can customize the one provided by hooking it up to your object model, or you can completely replace the table with the widget or widgets.
The next step is to modify the generated code by either changing or adding menus, menu items, tool bars, views, and editors as required.
Pages: 1, 2