Every RCP-Developer is familiar with this question. From a technical view the differences are very well explained by the authors from the eclipse3.0 faq. But is this really helpful? - Which criteria are really important in deciding which graphical components you’ll use? In this article I’ll share my experiences and decisions regarding views and editors.

The difference is not technical, its semantical

If you’re searching for the difference between views and editors you’ll find many websites that specify in a very detailled way the technical differences between views and editors, for example

• editors have a dirty state
• there is only one instance of a given view per workbench page
• editors have a so called editor-area
• local action-contribution vs. global action contribution
• ..

The problem is that these technical aspects do not help you design an application. The point of view needs to be more abstract, from a semantic point of view and also from a business perspective.

What’s the goal of your application?

90% of all applications have the same goal.- Editing data. If you’ll examine your requirements in an abstract context you’ll identify so called core-elements and helper-elements. A core-element is the smallest unit of a logical business-object, which is wired tightly to other core-elements. In addition, these core-elements are the indispensable parts of the whole context. When you build up your model you’ll see, that even the most complex business-objects consist of a only few core-elements (which does not necessarily mean that core elements are simple). Take a look at applications you’re using every day: For example a mail client with an integrated calender, and task-list (MS Outlook). If you analyze the context, you’ll identify the core objects:

• Mail
• Appointment
• Contact
• Task

These objects all have common behaviour. You may have collections of different core-elements, but you can only create/read/update/delete core-element as a whole (e.g., you cannot create only a half Contact) and for each core-element you have a completely different user interface. The ui-design of core-elements is a fundamental requirement, it is the key for the user understanding the workflow of your application. A big plus would be if the user understands the different wirings of the core-elements using intuitive application specific commands (e.g. shortcuts) or graphical components.

Giving the core a face

Core elements must be represented by editors. It “feels” different editing your data in an editor vs. editing your data in a view. This feeling is largely due to specific technical differences (e.g. the dirty state, that requires always an explicit user-interaction to save edited data, and the fixed position of editors). Analyze for yourself the differences in working with views and editors.

From Views and Helpers

Now, that we know which elements should be represented by editors, the question remains: “which views should be used?” The answer is quite simple:

• The most common use-cases are the helper-views for the active editor. The content of these views are adaptable objects that are wired to the content of the current active editor. In your model the content of these helper-views are mostly associations or compositions of your core-element (e.g., the familiar properties-view, the outline-view and the variables-view in the debug perspective). Eclipse already provides the functionality for such views (communication, activation, layout). Defining Adapters can make use the helper-view really simple. The enhancement of the properties-view to the tabbed-properties view is an example of this principle.
• The navigation structure is displayed in a view. This view content is not dependant on any other view or editor. The navigation content is almost always a singleton and is displayed in the the highest layer of your model (in Eclipse the Navigator-View, in Outlook the standard menu in the bottom left corner).
• Some features can be wrapped completely in a view. Models, actions and graphical elements that have no dependencies to other components of the application (for e.g., the Web-Browser View in MyEclipse).

Analyze existing software

Most larger software-vendors have already faced this problem and solved it. Look at the applications of Microsoft Office or from the Eclipse JDT. There you can find good examples for the different types of business-data and their relationship within your model.