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

Difference between revisions of "EMF Compare/Specifications/EditingTextualAttribute"

 
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Evolution Specification: Allow the edition textual attribute  =
+
{{Template:EMF Compare Archive Notice}}
  
Current status is '''DRAFT'''
+
= Evolution Specification: Allow the editing of textual attribute  =
 +
 
 +
Current status is '''ARCHIVED'''
  
 
== Preamble  ==
 
== Preamble  ==
  
Often, when comparing textual attribute, neither the local nor the remote value is the one the user wants to
+
This feature enables to directly edit a local value on either side of a textual difference (on text field of an object).
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.
+
  
<br> The possible status are (roughly inspired by [http://python.org/dev/peps/pep-0001/ PEP-0001]):
+
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=398083 Bug 398083]&nbsp;- Allow the edition textual attribute
  
*'''DRAFT''': Initial version and revisions based on internal feedback and discussions. DRAFT versions should never be made available outside of Obeo. They have version numbers 0.x.
 
  
*'''PROPOSAL''': When the document is considered ready for discussion with the client, it becomes a PROPOSAL. The first such version is numbered 1.0. Feedback from the client are integrated in further versions 1.x which are still PROPOSALs. Changes from one version to the next should be documented inside the document (as the client does not have access to the source repository).
+
== Introduction ==
 +
 +
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.
  
*'''ACCEPTED''': Once agreement has been reached with the client, the document becomes ACCEPTED.This version becomes the authoritative one for guiding the evolution's actual implementation. It should normally be considered freezed. Any change to it should be exceptional and subject to approval by the project manager. Such changes must be clearly documented and justified.
 
  
*'''ARCHIVED''': Once the evolution has been implemented _and_ its specification has been integrated into the reference documentation, this document is ARCHIVED. Any further change to the same features should be another __Viewpoint Evolution__ .
+
== Detailed Specification  ==
  
_Relevant tickets_ (links to the Bugzilla tickets which are related to the change):
+
On a textual difference, the user has to be able to edit his own value and, in this context, he will benefit from the features related to the text viewer like undo/redo mechanism during his editing session.
  
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=205420 Bug 205420]&nbsp;- EMF compare should handle contributions change
+
The models will be updated as soon as the user changes the input of the content merge viewer (on double-click on one of the structure viewer item), when he watches/handles an other difference or match. At the same time, the status of the "edited" difference will be set to REJECTED.
  
== Introduction  ==
+
In the other contexts, undo/redo action will enable to retrieve old/new set values (by textual editing or merge actions).
  
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.  
+
The save action shall set the current progressing textual editing in the model before serializing the data.  
  
== Detailed Specification  ==
 
  
This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:
+
== Backward Compatibility and Migration Paths ==
  
*a clear description of the objective, i.e. why the evolution is needed.
+
=== Metamodel Changes ===
*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  ==
+
This evolution does not change any metamodel.
  
Every one of the sections below should be present. Even if there is no corresponding change (for example no API change), it should exist to mention explicitly "This evolution does not change any API."
+
=== API Changes ===
  
=== Metamodel Changes  ===
+
This evolution required to get access to the change recorder from the editing domain (an accessor has been added to ICompareEditingDomain).
  
Document any change to the Viewpoint metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.
+
=== User Interface Changes ===
  
=== API Changes  ===
+
For now, the user can edit his own value on a text field concerned by a difference, on a local model.
  
List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.
+
=== Documentation Changes ===
  
=== User Interface Changes  ===
+
This documentation will have to be updated:
 +
*New and Noteworthy
 +
*User guide
  
List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.
 
  
=== Documentation Changes  ===
+
== Tests and Non-regression strategy ==
  
List every documentation needing an update here, starting by the New and Noteworthy documentation.  
+
A test case of the feature is presented here: [http://www.eclipse.org/emf/compare/doc/features/videos/Compare2/EditingText/editingText.htm video]
  
== Tests and Non-regression strategy  ==
+
=== Found bugs ===
 +
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=398311 Bug 398311] - ChangeRecoder with EditingDomain
 +
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=398405 Bug 398405] - The save action does not work in a content merge viewer different from TableContentMergeViewer
 +
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=398503 Bug 398503] - No refresh of the Structure Merge Viewer after setting a textual value
  
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  ==
 
== Implementation choices and tradeoffs  ==
  
Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.
+
During a textual editing session, it is possible to set each entered value in the model.
 +
 
 +
But, from the undo/redo mechanism viewpoint, it is not so relevant because each progressing step, during editing session, would be stored in the global command stack.
 +
So, this stack would be polluted by useless information, amongst other changed and set values coming from merges or textual editing actions.
  
[[Category:EMF Compare]]
+
Moreover, it would be needed to deactivate the local undo/redo mechanism on the text viewer because each undone or redone value would be set again and would modify this stack ! At last, the behavior would not be standard anymore and you should override the TextMergeViewer#configureTextViewer() method with your own configuration inheriting from SourceViewerConfiguration.

Latest revision as of 12:23, 5 March 2014

THIS PAGE IS ARCHIVED. IT IS PROBABLY OUTDATED AND WILL NOT BE UPDATED

Evolution Specification: Allow the editing of textual attribute

Current status is ARCHIVED

Preamble

This feature enables to directly edit a local value on either side of a textual difference (on text field of an object).


Introduction

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.


Detailed Specification

On a textual difference, the user has to be able to edit his own value and, in this context, he will benefit from the features related to the text viewer like undo/redo mechanism during his editing session.

The models will be updated as soon as the user changes the input of the content merge viewer (on double-click on one of the structure viewer item), when he watches/handles an other difference or match. At the same time, the status of the "edited" difference will be set to REJECTED.

In the other contexts, undo/redo action will enable to retrieve old/new set values (by textual editing or merge actions).

The save action shall set the current progressing textual editing in the model before serializing the data.


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

This documentation will have to be updated:

  • New and Noteworthy
  • User guide


Tests and Non-regression strategy

A test case of the feature is presented here: video

Found bugs

  • Bug 398311 - ChangeRecoder with EditingDomain
  • Bug 398405 - The save action does not work in a content merge viewer different from TableContentMergeViewer
  • Bug 398503 - No refresh of the Structure Merge Viewer after setting a textual value


Implementation choices and tradeoffs

During a textual editing session, it is possible to set each entered value in the model.

But, from the undo/redo mechanism viewpoint, it is not so relevant because each progressing step, during editing session, would be stored in the global command stack. So, this stack would be polluted by useless information, amongst other changed and set values coming from merges or textual editing actions.

Moreover, it would be needed to deactivate the local undo/redo mechanism on the text viewer because each undone or redone value would be set again and would modify this stack ! At last, the behavior would not be standard anymore and you should override the TextMergeViewer#configureTextViewer() method with your own configuration inheriting from SourceViewerConfiguration.

Back to the top