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.
Difference between revisions of "EMF Compare/Specifications/EditingTextualAttribute"
(→API Changes) |
(→User Interface Changes) |
||
Line 35: | Line 35: | ||
=== User Interface Changes === | === User Interface Changes === | ||
− | + | For now, the user can edit his own value on a text field concerned by a difference, on a local model. | |
=== Documentation Changes === | === Documentation Changes === |
Revision as of 17:56, 20 January 2013
Evolution Specification: Allow the editing of textual attribute
Current status is DRAFT
Preamble
Often, when comparing textual attribute, neither the local nor the remote value is the one the user wants to keep. We will relax the read-only constraint on textual compare viewer. As soon as the left or the right side is edited, the associated difference will be marked as rejected.
- Bug 398083 - Allow the edition textual attribute
Introduction
TODO: This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.
Detailed Specification
TODO: This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:
- a clear description of the objective, i.e. why the evolution is needed.
- a justification of the approach chosen. If other approaches were considered and rejected, document it for future reference.
- limits: things that are out of the scope of the evolution.
Backward Compatibility and Migration Paths
Metamodel Changes
This evolution does not change any metamodel.
API Changes
This evolution required to get access to the change recorder from the editing domain (an accessor has been added to ICompareEditingDomain).
User Interface Changes
For now, the user can edit his own value on a text field concerned by a difference, on a local model.
Documentation Changes
TODO: List every documentation needing an update here, starting by the New and Noteworthy documentation.
Tests and Non-regression strategy
TODO: This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.
Implementation choices and tradeoffs
TODO: Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.