Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/Doc/Saveable Life Cycle"
(Made a number of changes to improve the content style.) |
|||
| Line 3: | Line 3: | ||
[[Image:Service diagram.jpg|thumb|alt=Diagram of services in E4.|A placeholder diagram.]] | [[Image:Service diagram.jpg|thumb|alt=Diagram of services in E4.|A placeholder diagram.]] | ||
| − | Many applications require input | + | Many applications require user input to be persisted, or saved, between sessions. Given Eclipse's pluggable nature, having each new UI-enabled plugin provide mechanisms to invoke it's own save (for example from File->Save) would lead to a lot of redundant, boiler-plate code. E4 offers a consistent and greatly simplified way (over previous Eclipse versions) to allow UI Parts to save information and to notify the framework when a Part is dirty. |
== Relevant Terms == | == Relevant Terms == | ||
| − | + | Part - A part is a UI object in E4 that removes the distinction between Editor and View to provide more customizable properties. | |
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. | 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. | Editors & Views - Editors and views are UI objects that were created by the plugin in Eclipse 3.x and previous versions. | ||
| − | |||
== Motivation == | == Motivation == | ||
The distinction between Editors and Views in past versions of Eclipse was unnecessary. In e4, all high-level UI elements are instead classified as Parts, and Parts can be customized as required. | The distinction between Editors and Views in past versions of Eclipse was unnecessary. In e4, all high-level UI elements are instead classified as Parts, and Parts can be customized as required. | ||
| − | 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 | + | 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. |
| − | In previous versions of Eclipse, the code to do the save was implemented in a "save" method on the client object. In E4, to increase flexibility, | + | In previous versions of Eclipse, the code to do the save was implemented in a "save" method on the client object. In E4, 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 == | == Applicability == | ||
| Line 23: | Line 22: | ||
== Implementation == | == 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 | + | 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 | + | 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 === | === Auto-Save === | ||
| − | At this point E4 does not provide | + | At this point the E4 framework does not provide any auto-saving features (see: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=34076 here] ) however some proposed solutions are available in the aforementioned link. Developers are encouraged to contribute to the discussion. |
== Related Services == | == Related Services == | ||
| Line 34: | Line 33: | ||
*[[E4/Doc/Status Reporting|Status Reporting]] | *[[E4/Doc/Status Reporting|Status Reporting]] | ||
| − | == Unrelated | + | == Unrelated Services == |
| − | *Persisting | + | *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. |
Revision as of 04:13, 4 April 2010
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.
Many applications require user input to be persisted, or saved, between sessions. Given Eclipse's pluggable nature, having each new UI-enabled plugin provide mechanisms to invoke it's own save (for example from File->Save) would lead to a lot of redundant, boiler-plate code. E4 offers a consistent and greatly simplified way (over previous Eclipse versions) to allow UI Parts to save information and to notify the framework when a Part is dirty.
Contents
Relevant Terms
Part - A part is a UI object in E4 that removes the distinction between Editor and View to provide more customizable properties. 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
The distinction between Editors and Views in past versions of Eclipse was unnecessary. In e4, all high-level UI elements are instead classified as Parts, and Parts can be customized as required.
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.
In previous versions of Eclipse, the code to do the save was implemented in a "save" method on the client object. In E4, 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 features (see: here ) however some proposed solutions are available in the aforementioned link. Developers are encouraged to contribute to the discussion.
Related 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.