Eclipse RCP in Action

An Editorial CMS Client Based on Eclipse RCP - Part 2

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

<extension
        id="textFormInputField"
        name="%formInputField.text.name"
        point="com.subshell.sophora.eclipse.formInputFields">
        <formInputField
                class="com.subshell.sophora.eclipse.internal.editor.form.SingleStringField"
                multiple="false"
                propertyTypes="string,long,double">
        </formInputField>
</extension>

<extension
        id="copytextEditorComponent"
        name="%editorComponent.copytext.name"
        point="com.subshell.sophora.eclipse.editorComponents">
        <editorComponent
                class="com.subshell.sophora.eclipse.internal.editor.copytext.CopytextEditorComponent">
        </editorComponent>
</extension>

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

Conclusion

Using the Eclipse RCP framework in this project not only fulfilled the requirements for the editorial work at tagesschau.de (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.

Pages

Torsten Witte
Torsten Witte

What do you think?

JAX Magazine - 2014 - 06 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions