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
(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

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

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

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
). 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

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".
comments powered by Disqus