Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

E4/Doc/Saveable Life Cycle

< E4‎ | Doc
Revision as of 02:09, 8 April 2010 by Brentbarkman.gmail.com (Talk | contribs)

Under Construction: Please read first!

The evolution of this document is a collaborative effort between a team of students at the University of Manitoba and the wider Eclipse community. Details about the project can be found here and on our Blog.

Your input is not just welcome; it is needed! Please contribute as your expertise allows, while adhering to our template. To send your feedback and any questions or comments you may have please email us. Also, while we do our very best to be as accurate and precise as possible, it is worth noting that we are students with limited exposure to the Eclipse platform, so if you see any incorrect technical details please let us know.

Framework calls annotated save method on contributed UI object. MDirtyable is retrieved with dependency injection and used to set the Part dirty.

Many applications require user input to be persisted (or saved) between sessions. If each new plugin provided mechanisms to invoke its own save (for example from File->Save) there would be too much redundant, boiler-plate code. So, e4 offers a consistent and simple way to allow UI Parts to save information and to notify the framework when a Part is dirty.

Relevant Terms

  • Part - A Part is a UI object in e4 that is customizable with different properties through multiple inheritance.
  • Dirty - A Part is considered dirty when it has unsaved changes. A dirty state is typically denoted by a '*' beside the filename on a tab, for example.
  • Editors & Views - Editors and Views are UI objects that were created by the plugin in Eclipse 3.x and previous versions.

Motivation

In e4, all user contributed UI elements are derived from Parts and can be customized by inheriting from the appropriate interfaces.

The dirty bit is now stored in the model object instead of with the client object, thus removing the need for an extra event to be fired. Instead, the client object calls setDirty() on its model object to notify the framework that unsaved changes have been made.

To increase flexibility, any method can be marked with a @Save annotation and it will be called by the framework when a save is invoked.

Applicability

e4's saveable lifecycle features are suitable in any situation where a user needs to be able to save information.

Implementation

A class contributing to the UI can use dependency injection (@Inject) to get instances of the model object (the Part). Parts can be customized using multiple inheritance to implement interfaces like Dirtyable (MDirtyable in Java). These features allow developers to specify whether a part can become dirty, and to set it dirty or clean. Other customizations are provided by interfaces like Contribution and Item.

The signature of the save method can vary. It may also require a ProgressMonitor or a StatusHandler, in order to gain access to supporting services for the duration of the save. These services could, for example, be used to notify the user if a save fails, or to keep the user up to date on the progress of a long running operation (like a save over HTTP).

Auto-Save

At this point the e4 framework does not provide any auto-saving however you can find some discussion regarding this as well as some proposed solutions here. Developers are encouraged to contribute to the discussion.

Related Services

Unrelated Services

  • Persisting State & Data - There is an important distinction between these two services; Persisting State & Data is in fact a service which persists the current state of UI elements. For example, if a user alters the size of a table column the Persisting (UI) State & Data service ensures that the table will appear with the modified width every time it is displayed. In contrast, the Saveable Life Cycle service is responsible for storing user inputted data, such as a text document in an editor or information in a bug report.

Moving to E3 section

-mention distinction between editors and views In previous versions of Eclipse, the code to do the save was implemented in a "save" method on the client object.

Back to the top