<?php
/**
 * Copyright (c) 2014, 2018 Eclipse Foundation and others.
 *
 * This program and the accompanying materials are made
 * available under the terms of the Eclipse Public License 2.0
 * which is available at https://www.eclipse.org/legal/epl-2.0/
 *
 * Contributors:
 *    Christopher Guindon (Eclipse Foundation) - initial API and implementation
 *
 * SPDX-License-Identifier: EPL-2.0
 */
?>

<div class="col-xs-24">
  <p>
    <img
      src="/community/images/cms_eclipse/witte_autor.jpg" align="left" id="img_author" class="padding-10"/>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) &ldquo;Sophora&rdquo; from the
    German company subshell GmbH (<a href="http://www.subshell.com"
      target="_blank">http://www.subshell.com</a>). Sophora has proven
    itself during the last years at the editorial office of
    tagesschau.de, 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.
  </p>
  <p>
    <strong>by Torsten Witte</strong>
  </p>
  <p>
    In 2006, when a new content management system for the editorial
    office of <a href="http://www.tagesschau.de" target="_blank">tagesschau.de</a>
    [<a href="#biblio1">1</a>] 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 be than easily be extended with additional content via drag
    and drop. When using a desktop application several technical
    questions needed 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 [<a
      href="#biblio2">2</a>] (see <a href="#figure1">figure 1</a>).
  </p>
  <p><a name="figure1"></a><img src="/community/images/cms_eclipse/witte_deskclient_1.jpg" /></p>
  <p class="figure">
    Figure
    1: The Sophora Deskclient at <a href="http://www.tagesschau.de"
      target="_blank">tagesschau.de</a>
  </p>
  <h3>Administrative Point of View</h3>
  <p>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.
  </p>
  <p>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
  </p>
  <h3>Journalistic Point of View</h3>
  <p>
    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 &ldquo;Sophora Documents&rdquo; 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
    <a href="#figure1">figure 1</a>).
  </p>
  <p>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.
  </p>
  <blockquote>
    <h3>Sophora Documents</h3>
    <p>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.
    </p>
  </blockquote>
  <h3>Document Search Within the Deskclient</h3>
  <p>
    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 <em>ExtendedListViewer</em>, which
    extends the JFace <em>StructuredViewer</em>, has been added to the
    Deskclient. The elements of the <em>ExtendedListViewer</em>, i.e. the
    domain objects provided by the corresponding <em>IContentProvider</em>,
    are shown as arbitrary SWT controls created by an <em>IControlProvider</em>.
    The <em>IControlProvider</em> has to be set analogously to an <em>IContentProvider</em>
    at the <em>ExtendedListViewer</em>. 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 <em>IControlProvider</em>. This
    way individual search result entries are updated immediately. For
    example, a user modifies the headline of 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 <em>IControlProvider</em>. <a href="#figure2">Figure 2</a>
    illustrates the different display modes: Single line, compact and
    gallery.
  </p>
  <p><a name="figure2"></a><img src="/community/images/cms_eclipse/witte_deskclient_2.jpg" /></p>
  <p class="figure">
   Figure
    2: ExtendedListViewer with different display modes
  </p>
  <h3>The Document Editor</h3>
  <p>
    The editor concept of the RCP eases the development of customised
    editors. For every domain object you can implement a corresponding <em>EditorPart</em>
    together with an <em>IEditorInput</em>. By extending the <em>MultiPageEditorPart</em>
    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.
  </p>
  <p>
    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 <em>DocumentEditorInput</em> 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 <em>doSave()</em>
    method and an error message is returned if necessary.
  </p>
  <p>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:
  </p>
  <ul>
    <li><em>IFormField:</em> Input field types for primitive data types,
      like text, date or selection fields.
    </li>
    <li><em>IEditorComponent:</em> 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
      &ldquo;Copytext Editor Component&rdquo; below).
    </li>
  </ul>
  <p>
    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 <em>plugin.xml</em>.
  </p>
  <h3>Listing 1</h3>
  <pre id="listing1">
&lt;extension
  id="textFormInputField"
  name="%formInputField.text.name"
  point="com.subshell.sophora.eclipse.formInputFields"&gt;
  &lt;formInputField
    class="com.subshell.sophora.eclipse.internal.editor.form.SingleStringField"
    multiple="false"
    propertyTypes="string,long,double"&gt;
  &lt;/formInputField&gt;
&lt;/extension&gt;

&lt;extension
  id="copytextEditorComponent"
  name="%editorComponent.copytext.name"
  point="com.subshell.sophora.eclipse.editorComponents"&gt;
  &lt;editorComponent
    class="com.subshell.sophora.eclipse.internal.editor.copytext.CopytextEditorComponent"&gt;
  &lt;/editorComponent&gt;
&lt;/extension&gt;
</pre>
  <h3>The Copytext Editor Component</h3>
  <p>
    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. <a
      href="#figure3">Figure 3</a> illustrates the composition of the
    copytext editor component, the so-called Copytext Editor.
  </p>
  <p class="figure">
    <a name="figure3"></a><img
      src="/community/images/cms_eclipse/witte_deskclient_3.jpg" />Figure
    3: Copytext Editor
  </p>
  <p>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 than 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.
  </p>
  <h3>The Implementation of the Copytext</h3>
  <p>
    To get started, SWT offers the <em>StyledText</em> widget [<a
      href="#biblio3">3</a>] that allows you to manage texts with the <em>StyledTextContent</em>
    and to format them with <em>StyleRanges</em>. 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 <em>TextViewer</em>, which operates on an <em>IDocument</em>
    as model. This turned out to not entirely satisfy the specifications.
    However, the <em>SourceViewer</em>, which is a subclass of <em>TextViewer</em>,
    in combination with the remaining interfaces and classes from the <em>org.eclipse.jface.text.source
    package</em> serves as a point of entry for the copytext editor
    component's implementation.
  </p>
  <p>
    <a href="#figure4">Figure 4</a> illustrates that the <em>CopytextViewer</em>
    extends the <em>RichtextViewer</em>, which in turn, inherits the
    JFace <em>SourceViewer</em>. The <em>RichtextViewer</em> is a
    reusable component for additional input fields for formatted text but
    without figures and boxes and so on. The model of the <em>CopytextViewer</em>
    is a <em>CopytextDocument</em>, which holds the individual
    paragraphs.
  </p>
  <p class="figure">
    <a name="figure4"></a><img
      src="/community/images/cms_eclipse/witte_deskclient_4.jpg" />Figure
    4: Inheritance hierarchy of the CopytextViewer
  </p>
  <p>In contrast to the <em>TextViewer</em>, the <em>SourceViewer</em> has an additional
    <em>IverticalRuler</em> in the form of a left-hand margin that displays
    details and contains smaller configurational items. The
    <em>CopytextViewer</em> 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 <em>SourceViewer</em> is configured with a
    <em>SourceViewerConfiguration</em>, which allows the addition of a spell
    checker.
  </p>
  <p>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 <em>RichtextViewer</em>. 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 <em>StyledCellLabelProvider</em> improved support in that direction
    [<a
      href="#biblio4">4</a>]). Also, it was difficult to actually draw table cells when some
    cells were higher than others. As for boxes within text, the
    <em>ExtendedListViewer</em> 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 <em>CopytextViewer.lineGetStyle()</em> method that returns a <em>StyleRange</em>
    object with <em>GlyphMetrics</em>. Finally, the <em>CopytextViewer</em> implements the
    <em>PaintObjectListener</em> interface and therewith assures that tables and
    boxes appear at their correct positions.
  </p>
  <h3>Target Platform(s)</h3>
  <p>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.
  </p>
  <p>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 that 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 &ldquo;deprecated&rdquo;. Most of them could be worked off via content
    assist.
  </p>
  <p>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).
  </p>
  <h3>Conclusion</h3>
  <p>Using the Eclipse RCP framework in this project not only fulfilled
    the requirements for the editorial work at <a href="http://www.tagesschau.de" target="_blank">tagesschau.de</a> (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.
  </p>
  <p>
    <em>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".</em>
  </p>
  <h4>Conclusion</h4>
  <ul>
    <li><a name="biblio1"></a>[1] <a href="http://www.tagesschau.de"
      target="_blank">www.tagesschau.de</a></li>
    <li><a name="biblio2"></a>[2] <a
      href="http://www.subshell.com/en/sophora/" target="_blank">www.subshell.com/en/sophora/</a>
    </li>
    <li><a name="biblio3"></a>[3] <a
      href="http://www.eclipse.org/articles/StyledText%202/article2.html"
      target="_blank">http://www.eclipse.org/articles/StyledText%202/article2.html</a>
    </li>
    <li><a name="biblio4"></a>[4] <a
      href="http://archive.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/whatsnew3.4/eclipse-news-part3.html"
      target="_blank">http://archive.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/whatsnew3.4/eclipse-news-part3.html</a>
    </li>
  </ul>
  <p>
    Note: This article was first published in German in the February,
    2011, issue of &ldquo;Eclipse Magazin&rdquo; (<a
      href="http://www.eclipse-magazin.de" target="_blank">http://www.eclipse-magazin.de</a>).
    An online version of the article can be found at <a
      href="http://it-republik.de/jaxenter/artikel/Eclipse-bei-der-Tagesschau-3748.html"
      target="_blank">http://it-republik.de/jaxenter/artikel/Eclipse-bei-der-Tagesschau-3748.html</a>.
    Published with kind permission of Software &amp; Support Verlag GmbH.
  </p>
</div>