7.9. RFRS Considerations

The "User Interface" section of the RFRS Requirements includes seven itemsfive requirements and two best practicesdealing with views. All of them are derived from the Eclipse UI Guidelines.

7.9.1. Views for navigation (RFRS 3.5.15)

User Interface Guideline #7.1 is a requirement that states:

Use a view to navigate a hierarchy of information, open an editor, or display the properties of an object.

To pass this test, create a list of the views defined by your application and demonstrate how they are used to navigate information, open editors, or display the properties of some object. In the case of the examples presented earlier in this chapter, show the Favorites view (see Figure 10-4 on page 393) and describe its use to the reviewers. In particular, double-clicking on a file in the Favorites view will open the file in an editor.

7.9.2. Views save immediately (RFRS 3.5.16)

User Interface Guideline #7.2 is a requirement that states:

Modifications made within a view must be saved immediately. For instance, if a file is modified in the Navigator, the changes must be committed to the workspace immediately. A change made in the Outline view must be committed to the edit model of the active editor immediately. For changes made in the Properties view, if the property is a property of an open edit model, it should be persisted to the edit model. If it is a property of a file, persist it to file. In the past, some views have tried to implement an editor-style lifecycle with a save action. This can cause confusion. The File menu within a workbench window contains a Save action, but it only applies to the active editor. It will not target the active view. This can lead to a situation where the File > Save action is in contradiction with the Save action within the view.

For this test, show how changes made in your view are saved immediately. If your view updates an existing editor, make sure that the editor is immediately marked as dirty and shows the modification indicator (*). Further, show that the Save menu does not need to be invoked for the view to save its changes.

7.9.3. View initialization (RFRS 3.5.17)

User Interface Guideline #7.8 is a requirement that states:

When a view first opens, derive the view input from the state of the perspective. The view may consult the perspective input or selection, or the state of another view. For instance, if the Outline view is opened, it will determine the active editor, query the editor for an outline model, and display the outline model.

To pass this test, show that your view reflects the input state of the perspective (if appropriate). If your view is meant to show some attribute of the selected editor, make sure that when it is opened it displays the appropriate information. For the Favorites view, this requirement probably does not apply. The Favorites view could be extended to update its own selection to reflect the currently active editor.

7.9.4. View global actions (RFRS 3.5.18)

User Interface Guideline #7.19 is a requirement that states:

If a view has support for cut, copy, paste, or any of the global actions, the same actions must be executable from the same actions in the window menu and toolbar. The window menu contains a number of global actions, such as cut, copy, and paste in the Edit menu. These actions target the active part, as indicated by a shaded title area. If these actions are supported within a view, the view should hook these window actions so that selection in the window menu or toolbar produces the same result as selection of the same action in the view. The following are the supported global actions: undo, redo, cut, copy, paste, print, delete, find, select all, and bookmark.

For this requirement, if your view implements any of the items on the global action list, show that those commands can also be invoked from the window menus and toolbars. For the Favorites view, show that the Cut, Copy, Paste, and Delete (Remove) commands can be invoked from the platform Edit menu.

7.9.5. Persist view state (RFRS 3.5.19)

User Interface Guideline #7.20 is a requirement that states:

Persist the state of each view between sessions. If a view is self-starting in the sense that its input is not derived from selection in other parts, the state of the view should be persisted between sessions. Within the workbench, the state of the Navigator view, including the input and expansion state, is saved between sessions.

Show that your view persists its state between sessions. For the Favorites view, shut down and restart the workbench and show that the Favorites items appearing in the list are the same ones that were there when the workbench was shut down.

7.9.6. Register context menus (RFRS 5.3.5.8)

User Interface Guideline #7.17 is a best practice that states:

Register all context menus in the view with the platform. In the platform, the menu and toolbar for a view are automatically extended by the platform. By contrast, the context menu extension is supported in collaboration between the view and the platform. To achieve this collaboration, a view must register each context menu it contains with the platform.

Show that the context menu of your view is extensible by the platform. If the platform defines commands that are appropriate for the objects contained in your view, those commands should appear in the view's context menu. For the Favorites view, show that common Eclipse commands such as "Replace With" and "Compare With" appear when you right-click on a Favorites item (see Figure 7-9).

Figure 7-9. Favorites view showing platform contributions to the context menu.

[View full size image]

7.9.7. Action filters for views (RFRS 5.3.5.9)

User Interface Guideline #7.18 is a best practice that states:

Implement an action filter for each object type in the view. An action filter makes it easier for one plug-in to add an action to objects in a view defined by another plug-in. An action target is described using object type and attributes.

As with the previous best practice, show that any commands contributed to your view's context menu are appropriate to the type of the selected object. Commands that don't apply should be filtered out. For the Favorites view, show that the platform commands contributed to the context menu are context-sensitive based on the type of object selected (see Figure 7-10).

Figure 7-10. Favorites view showing that context menu items are filtered based on their type (projects show items other than files).

[View full size image]