Undo Redo Design - Revision history

imported>Mathieu at 09:27, 4 March 2009

2009-03-04T09:27:13Z

← Older revision		Revision as of 09:27, 4 March 2009
Line 26:		Line 26:


	~~[[Category:Work in progress]]~~
	[[Category:Design]]		[[Category:Design]]

imported>Mathieu: typo + title change

2008-10-27T13:49:52Z

typo + title change

← Older revision		Revision as of 13:49, 27 October 2008
Line 7:		Line 7:
	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.		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.

	== ~~Operations~~ ==		== 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.		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.
Line 15:		Line 15:
	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().		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().

	== ~~Factory~~ ==		== Available Interface ==

	The interface provided to clients consists of three class:		The interface provided to clients consists of three class:
	* {{class\|OperationFactory}}		* {{class\|OperationFactory}}
	* {{class\|History}}		* {{class\|History}}
	* ~~[[classAtomicOperation~~}}		* {{class\|AtomicOperation}}

	The factory may not be instantiated and its methods are static. {{class\|History}}		The factory may not be instantiated and its methods are static. {{class\|History}}

imported>Mathieu: Some small rewritting and typesetting

2008-10-27T13:45:46Z

Some small rewritting and typesetting

← Older revision		Revision as of 13:45, 27 October 2008
Line 1:		Line 1:
	== History Mechanism ==		== History Mechanism ==

	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 History and interface IUndoableOperation. Each operation has 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()}}.

	~~Operations~~ 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.		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 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.		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.

	== Operations ==		== Operations ==

	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.		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.

	Some operations are dependent on an element in their execution (e.g., 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 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 delegate its methods but it encapsulates in the RodinCore.run().

			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()}}.

			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().

	== Factory ==		== Factory ==

	The interface ~~provides~~ to clients consists of three class:		The interface provided to clients consists of three class:
	* OperationFactory		* {{class\|OperationFactory}}
	* History		* {{class\|History}}
	* ~~AtomicOperation~~		* [[classAtomicOperation}}

	The factory is not ~~instantiable~~ and its methods are static. History		The factory may not be instantiated and its methods are static. {{class\|History}}
	implements the pattern Singleton and delegates to IOperationHistory.		implements the pattern {{class\|Singleton}} and delegates to {{class\|IOperationHistory}}.


	[[Category:Work in progress]]		[[Category:Work in progress]]
	[[Category:Design]]		[[Category:Design]]

imported>Mathieu: cat

2008-10-27T13:33:27Z

cat

← Older revision		Revision as of 13:33, 27 October 2008
Line 26:		Line 26:
	The factory is not instantiable and its methods are static. History		The factory is not instantiable and its methods are static. History
	implements the pattern Singleton and delegates to IOperationHistory.		implements the pattern Singleton and delegates to IOperationHistory.


			[[Category:Work in progress]]
			[[Category:Design]]

imported>Laurent at 17:19, 20 October 2008

2008-10-20T17:19:35Z

← Older revision		Revision as of 17:19, 20 October 2008
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 History and interface IUndoableOperation. Each operation has three methods to act on the database: execute(), undo() and 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.~~

	~~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~~.

			Operations 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.

	== Operations ==		== Operations ==

	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~~.		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 (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()		Some operations are dependent on an element in their execution (e.g., 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 are called by execute()


	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().		Then to ensure atomicity with respects to the Rodin database, composite operations (TreeOperation) are encapsulated in a class AtomicOperation. It only delegate its methods but it encapsulates in the RodinCore.run().

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...

2008-10-16T09:06:36Z

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...

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/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().

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.

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.

== Operations ==

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.

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()

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().

== Factory ==

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.