Eclipse RCP in Action

An Editorial CMS Client Based on Eclipse RCP


Software engineer Torsten Witte presents a case study of the “Sophora” content management system.

Use of rich client applications based on Eclipse RCP has increased widely in recent years, both in the open source and in the commercial field. Eclipse RCP is employed more and more in sections where web clients were predominantly in use. One good example of this development is the content management system (CMS) “Sophora” from the German company subshell GmbH ( Sophora has proven itself during the last years at the editorial office of, Germany’s leading news homepage. This article describes the experience of subshell’s development team while developing the Sophora Deskclient and the article outlines certain obstacles the team encountered, and their resolutions.

In 2006, when a new content management system for the editorial office of was in development, the primary goal of the editorial staff was clearly stated: publishing articles must be effective and efficient. Journalists should be supported so that they can focus on content rather than on the website’s (or any other channel’s) layout when writing news. Images as well as audio and video content need to be placed in or around the text easily and without delay. These challenges led to the development of a desktop application that contains the structured content of each article and that can then be easily extended with additional content via drag and drop.

When using a desktop application, several technical questions need to be posed in advance. Which operating systems will be supported? How will the application be distributed and installed on the different workstations? How will required updates be executed? How will user specific configurations be handled when the user switches workstations? These problems were unique challenges for subshell; they do not often emerge when working with web clients. At last, a solution was found. The Eclipse RCP framework was chosen as the technology for a rich-client, the so-called Sophora Deskclient (see figure 1).

Administrative Point of View

The Eclipse RCP framework already answers some of the needs mentioned above. Installing the rich-client can be omitted since the application only needs to be extracted to a workstation’s hard drive. A central update site is used to deliver required updates and to provide the latest software version. Upon the Deskclient’s start-up, new updates are automatically installed. Alternatively, the application can be rolled-out by using an existing, internal software deployment system. The individual settings are stored in the central home directories so that they are retained when users change workstations.

In addition, the plug-in framework provides the point of entry for any future product extensions that are not enclosed in the standard version. The manufacturer can assemble the Deskclient with the help of flexible build configurations and can deploy different variants of the same core product, e.g., for different operating systems like Windows, Linux or Mac OS. It is also possible to integrate project specific plug-ins.

The Sophora CMS is a document-oriented system. For a journalist this means that he or she never edits the website as a whole but instead focuses on single documents that are later assembled to form the actual website. Every document has a document type, which can be defined and configured freely. Example document types are homepage, story, breaking-news, image, slide-show, audio, video, link, filter, broadcast, form, download, survey, chronicle and so on. Each document contains the information that is needed to be referenced by another document and to be displayed on the website in the context of this document. For example, all story documents contain a headline and a teaser text, as well as a teaser image, all of which are used to announce them on an index page.

Journalistic Point of View

The Eclipse RCP framework presents a well-arranged user interface by dividing the workspace into views and editors, and therefore allows each journalist to customise their alignment individually. For example, the Sophora Deskclient provides one view that contains the entire search function. Retrieved documents can be opened in the editor section from this view (see box “Sophora Documents” for more information about documents within Sophora). The component structure (deduced from Eclipse’s outline view), which displays all documents referenced by the document at hand, is another example of this technology. The modified property sheet page, called component details, consists of detailed information about the component that is selected in the component structure view. It further provides a way to override these details in the context of the current document (see figure 1).

For an editorial journalist it is commonplace to not only edit multiple documents at a time but also to drag and drop documents from other views into the current workspace. Users can rearrange the views to meet their individual requirements and to best support their workflow. For example, they can even detach a view from the parent window and move the preview view to another monitor to revise and view their changes as they would appear on the website. This way of working is more fluid and better supports a busy editorial office.

Sophora Documents

The Sophora CMS is a document-oriented system. For a journalist this means that he or she never edits the website as a whole but instead focuses on single documents that are later assembled to form the actual website. Every document has a document type, which can be defined and configured freely. Example document types are homepage, story, breaking-news, image, slide-show, audio, video, link, filter, broadcast, form, download, survey, chronicle and so on. Each document contains the information that is needed to be referenced by another document and to be displayed on the website in the context of this document. For example, all story documents contain a headline and a teaser text, as well as a teaser image, all of which are used to announce them on an index page.

Document Search Within the Deskclient

The search mechanism is one key element of the Deskclient with which users find documents they want to modify or use. A user has to identify those documents relevant to him or her, based on the displayed information within the search result list. This includes the document’s status as well as content information such as document type, headline, thumbnail, last modifier of the document, modification date and other potentially interesting facts which might depend on the document’s type. The results of this search query list as a simple SWT list or table would have been confusing and not very user-friendly. Therefore, an ExtendedListViewer, which extends the JFace StructuredViewer, has been added to the Deskclient. The elements of the ExtendedListViewer, i.e. the domain objects provided by the corresponding IContentProvider, are shown as arbitrary SWT controls created by an IControlProvider. The IControlProvider has to be set analogously to an IContentProvider at the ExtendedListViewer. The ExtendedListViewer then manages the generated controls. When list elements need to be updated, the corresponding controls are removed from the internal cache and requested again from the IControlProvider. This way, individual search result entries are updated immediately. For example, a user modifies the headline of the document while it is displayed in the search result list of another user’s Deskclient. As a result, the presentation of the search results is interchangeable due to the IControlProvider. Figure 2 illustrates the different display modes: Single line, compact and gallery.

The Document Editor

The editor concept of the RCP eases the development of customised editors. For every domain object you can implement a corresponding EditorPart together with an IEditorInput. By extending the MultiPageEditorPart you can even summarise multiple editors across multiple tabs in one document editor. The Sophora Deskclient required a generic editor solution, since the individual document types should not each come with a corresponding editor implementation. This would not only have increased maintenance but would also have implied that each new (project specific) document type requires its own editor implementation. In addition, such a new implementation would have triggered another rollout of a new version of the application.

With this in mind, the Sophora document editor is built in such a way that it applies for arbitrary document types. Administrators may create new document types and define which fields exist, whether these fields are mandatory or not, where they occur (on which tab of the editor), how they are labelled, which input field types they use (plain text, drop-down selection, check-box and the like) and many more. When a document is opened this configuration is read from the corresponding DocumentEditorInput and dynamically determines the actual appearance of the editor. When a document is saved, a validation of the individual input fields is initiated within the doSave() method and an error message is returned if necessary.

The existing plug-in framework is utilised in order to gain the same flexibility for the entire set of available input field types. In principle, two kinds of input field types are distinguished within the Deskclient:

  • IFormField: Input field types for primitive data types, like text, date or selection fields.
  • IEditorComponent: Input field types with an underlying model for complex data types. For example, an image editor or a rich-text field for formatted and structured text (see section “Copytext Editor Component” below).

There is an extension point for both kinds of fields where every input field type is declared. Thus, further input field types can be added by additional plug-ins. This behaviour has been used to integrate an input field type for geographical coordinates (based on Bing maps), which links a document to a certain location. Another example for such a product extension is an input field type for teletext pages. Listing 1 contains an exemplary declaration of a simple text field and the copytext editor component within the plugin.xml.

Listing 1



The Copytext Editor Component

The greatest challenge while developing the Deskclient was the implementation of an editor component for handling rich-text for news articles, for example. Such content has to be easily created with all its paragraphs, headlines, simple formatting (bold, italic and lists), links, figures, barrier-free tables, mark-ups (like citation, language or abbreviations) and boxes that contain references to related documents. Of course, a built-in spell checker is at hand. Figure 3 illustrates the composition of the copytext editor component, the so-called Copytext Editor.

The copytext editor is not a WYSIWYG editor. Instead, it captures the actual text in a structured way and stores it in a corresponding model (from which all content information can then again be retrieved). How the content will be displayed on the website or any other delivery channel depends on the implementation of a project’s delivery, and is distinct from the presentation within the editor.

The Implementation of the Copytext

To get started, SWT offers the StyledText widget that allows you to manage texts with the StyledTextContent and to format them with StyleRanges. But when considering figures and tables within text, this implementation reaches its limits. JFace also uses this widget and extends the viewer framework by an according TextViewer, which operates on an IDocument as model. This turned out to not entirely satisfy the specifications. However, the SourceViewer, which is a subclass of TextViewer, in combination with the remaining interfaces and classes from the org.eclipse.jface.text.source package serves as a point of entry for the copytext editor component’s implementation.

Figure 4 illustrates that the CopytextViewer extends the RichtextViewer, which in turn, inherits the JFace SourceViewer. The RichtextViewer is a reusable component for additional input fields for formatted text but without figures and boxes, and so on. The model of the CopytextViewer is a CopytextDocument, which holds the individual paragraphs.

In contrast to the TextViewer, the SourceViewer has an additional IverticalRuler in the form of a left-hand margin that displays details and contains smaller configurational items. The CopytextViewer uses this margin to show the paragraph styles and thumbnails of inserted images. Users can here change the paragraph styles, as well as drag and drop images in order to include them. Moreover, the SourceViewer is configured with a SourceViewerConfiguration, which allows the addition of a spell checker.

New composites were required to solve the remaining problems with tables and boxes. The table composite was designed to add and remove rows and columns, to format text within table cells, and to paste content from third-party systems like MS Excel or OpenOffice. Every table cell utilises the already mentioned RichtextViewer. The existing SWT or JFace implementation was insufficient due to its lack of formatting possibilities within table cells (not until Eclipse 3.4 when the StyledCellLabelProvider improved support in that direction). Also, it was difficult to actually draw table cells when some cells were higher than others. As for boxes within text, the ExtendedListViewer from the search component had been reused within another new composite to display the referenced documents. The presentation of both tables and boxes further required the reservation of the space needed in the text container, in order to prevent text from being hidden behind a table or box. This is ensured by the CopytextViewer.lineGetStyle() method that returns a StyleRange object with GlyphMetrics. Finally, the CopytextViewer implements the PaintObjectListener interface and therewith assures that tables and boxes appear at their correct positions.

Target Platform(s)

Everyone who develops Eclipse RCP applications knows that a target platform is mandatory. On the one hand, it is used as a skeleton for the created software and supports different operating systems. On the other hand, it separates the application and the programming environment. For instance, you can develop an application based on Eclipse 3.5 while using Eclipse 3.6 as IDE. Furthermore, the development environment remains unconcerned from plug-ins needed for the application and vice versa.

When the development of the Sophora Deskclient started, the target platform was Eclipse SDK 3.2.2 including the delta and language pack. This version stayed on duty for a long period of time. One reason was that the language packages in later versions have either been terminated or replaced by the Babel project and seemed unstable. At first, changing the target platform was not necessary from a technical point of view. But when new requirements emerged to support newer operating systems, the target platform had to be exchanged. The changeover to Eclipse 3.4 as the target platform was tested in a separate branch, but never came into action. The effort to switch proved to be marginal; therefore, Eclipse 3.5.0 was made the new target platform as soon as it had been published. Few classes and methods had to be replaced by recommended interfaces since they were marked as “deprecated”. Most of them could be worked off via content assist.

Presently, Eclipse 3.5.2 is in charge. The next changeover to Eclipse 3.6, 3.7 or even 4.1 is expected to happen without any trouble. In fact, there is an expectation of significant benefits and improvements from new features and improvements (for example, Equinox p2, CSS styled widgets and so on).


Using the Eclipse RCP framework in this project not only fulfilled the requirements for the editorial work at (where work must be quick and efficient), but also provided distinct technical advantages. The RCP framework constitutes a solid foundation for rich-client applications. Views, editors, actions, commands, wizards, preference pages, selection services, adapter pattern, help framework, extensions and extension points should be part of a RCP developer’s vocabulary. The implementation of the copytext editor component was complicated but the effort was well worth it. Meanwhile, the Sophora CMS has been established in numerous broadcast stations in Germany. The editorial journalists are more than satisfied and enjoy their daily work with Sophora.

Torsten Witte is computer scientist and works as software engineer at subshell GmbH in Hamburg, Germany. He has extended experience in developing Java and rich-client applications based on Eclipse RCP. He is a member of the development team of the Content Management System "Sophora" and the Java Content Repository (JCR) Tool "Toromiro".

Inline Feedbacks
View all comments