Browse Prior Art Database

Using model change notifications to implement the command pattern

IP.com Disclosure Number: IPCOM000129167D
Original Publication Date: 2005-Sep-29
Included in the Prior Art Database: 2005-Sep-29
Document File: 7 page(s) / 98K

Publishing Venue

IBM

Abstract

The present publication is directed to a method for enabling editors to manipulate objects with "undo" and "redo" support.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 25% of the total text.

Page 1 of 7

Using model change notifications to implement the command pattern

1. Introduction

Many modeling frameworks support model change notifications. These are events emitted by a modeling object upon changing the object's state, i.e. modifying the object's data members. If a notification has enough information about the model change, it is possible to rely on this information to undo or redo this model change. If this information identifies the changed object, the changed data member in that object, the old value and the new value of the data member, then it seems that this information may be enough to: - revert the object to its previous state before the model change(undo); - replicate the model change(redo).

Now we can take this basic idea a step further and encapsulate a set of model changes inside a command. If we can buffer the resulting notifications inside the command, then the command can implement undo by reverting the effect of every notification and implement redo by replicating the effect of every notification. To do that, a notification must contain sufficient information about the model change.

2. Background art

A known technique for supporting undo in a software application is to implement a layer of basic commands above any metamodel has been generated to enable editors to manipulate objects with "undo" and "redo" support. A basic command for a given metamodel class provided accessor methods (setters) to modify the structural features of an object of that class. For example, with the following simple Employee class,

Employee

name : String salary : Double

an editor can use the following basic command to update an Employee object:

UpdateEmployeeCmd

setNam e(name : String) setSalary (salary : Double) execut e() : void undo() : void redo() : void

Please note that: - The editor passes the Employee object that he desires to modify to the originator of the UpdateEmployeeCmd command. - The accessor methods (such as setName()) don't actually modify the Employee object. Instead, the new values are temporarily buffered in the UpdateEmployeeCmd command. Then, when the caller invokes execute(), the object is modified as per the values passed to the accessor methods. - The execute() method relies on reflection to manipulate the underlying object. - The caller can invokes undo() to return the object to its previous state (just before

1

[This page contains 21 pictures or other non-text objects]

Page 2 of 7

invoking execute()). - After invoking undo(), the caller can invoke redo() to re-apply the effects of the command. - Each basic command can manipulate only objects belonging to a single class. The present publication disclose a method to implement the famous command pattern based on model change notifications (or notifications in short).

3. Prerequisites:
a. A modeling framework that supports reflection

Reflection is necessary to manipulate objects without any knowledge of the metamodel classes. The Eclipse Modeling Framework (emf) is...