Difference between revisions of "Undo Redo Design"

From Event-B
Jump to navigationJump to search
imported>Aurelien
(New page: == Eclipse History == To implement the history, we have based mechanism History provided by Eclipse [http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference...)
 
imported>Mathieu
m
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
== Eclipse History ==
+
== History Mechanism ==
  
−
To implement the history, we have based mechanism History provided by Eclipse [http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/commands/operations/package-summary.html]. It is consist of a class History and an interface IUndoableOperation. The operations have three methods to act on the database: execute(), undo() and redo().
+
Undo / Redo is built on top of the history mechanism provided by Eclipse [http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/guide/wrkAdv_undo.htm]. It is composed of class {{class|History}} and interface {{class|IUndoableOperation}}. Each operation has three methods to act on the database: {{ident|execute()}}, {{ident|undo()}} and {{ident|redo()}}.
  
−
They are saved in the historic which call execute() for the first time and then undo () and redo () as the operation is to undo or redo.
+
Database changes are added to the history.  The {{ident|execute()}} operation is called during addition. Then, operations {{ident|undo()}} and {{ident|redo()}} are executed by the history when an Undo or Redo action is performed.
  
−
As a file must have its own historic, the operations have a context, here it's the name of file. A History class then manages the historic of all files.
+
As each file has its own history, every operation has a context, which is the name of the file. The {{class|History}} class just manages the history of all files.
  
 +
== Implementation for Rodin ==
  
 +
First, we have to make objects that implement {{class|IUndoableOperation}} for each transaction on the database. We use the composite model so that each operation is composed of basic operations (add an element, delete an element, change an attribute ,...). The operations are created by a factory.
  
−
== Operations ==
+
Some operations are dependent on an element in their execution (e.g., change an attribute). This may not be known when recording the operation in the History. To do this, operations have methods {{ident|getCreatedElement()}} and {{ident|setParent()}} which are called by {{ident|execute()}}.
  
−
First, we have to make objects that implements IUndoableOperation for each transaction on the data base. We use the composite model so that each operation is composed of basic operations (add an element, delete an element, change an attribute ,...). The operations are created by class builder.
+
Then to ensure atomicity with respects to the Rodin database, composite operations ({{class|TreeOperation}}) are encapsulated in a class {{class|AtomicOperation}}. It only delegates its methods but it encapsulates in the RodinCore.run().
  
−
Some operations are dependent on an element in their execution (eg change an attibute). This may not be known when recording the operation in the History. To do this, operations have methods getCreatedElement () and setParent () which be called in execute()
+
== Available Interface ==
−
 
  
−
Then to ensure the atomicity on the database, operations (TreeOperation) are encapsulated in a class AtomicOperation. It only delegate its methods but it encapsulates in the RodinCore.run().
+
The interface provided to clients consists of three class:
 +
* {{class|OperationFactory}}
 +
* {{class|History}}
 +
* {{class|AtomicOperation}}
  
 +
The factory may not be instantiated and its methods are static. {{class|History}}
 +
implements the pattern {{class|Singleton}} and delegates to {{class|IOperationHistory}}.
  
  
−
== Factory ==
+
[[Category:Design]]
−
 
 
−
The interface provides to clients consists of three class:
 
−
* OperationFactory
 
−
* History
 
−
* AtomicOperation
 
−
 
 
−
The factory is not instantiable and its methods are static. History
 
−
implements the pattern Singleton and delegates to IOperationHistory.
 

Latest revision as of 09:27, 4 March 2009

History Mechanism

Undo / Redo is built on top of the history mechanism provided by Eclipse [1]. It is composed of class History and interface IUndoableOperation. Each operation has three methods to act on the database:

execute()

,

undo()

and

redo()

. Database changes are added to the history. The

execute()

operation is called during addition. Then, operations

undo()

and

redo()

are executed by the history when an Undo or Redo action is performed.

As each file has its own history, every operation has a context, which is the name of the file. The History class just manages the history of all files.

Implementation for Rodin

First, we have to make objects that implement IUndoableOperation for each transaction on the database. We use the composite model so that each operation is composed of basic operations (add an element, delete an element, change an attribute ,...). The operations are created by a factory.

Some operations are dependent on an element in their execution (e.g., change an attribute). This may not be known when recording the operation in the History. To do this, operations have methods

getCreatedElement()

and

setParent()

which are called by

execute()

.

Then to ensure atomicity with respects to the Rodin database, composite operations (TreeOperation) are encapsulated in a class AtomicOperation. It only delegates its methods but it encapsulates in the RodinCore.run().

Available Interface

The interface provided to clients consists of three class:

  • OperationFactory
  • History
  • AtomicOperation

The factory may not be instantiated and its methods are static. History implements the pattern Singleton and delegates to IOperationHistory.

Retrieved from ‘https://wiki.event-b.org/index.php?title=Undo_Redo_Design&oldid=10566’