Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a GWT website that displays some data onto the client in a tabular form. Some of the fields are editable, when any change is made the save button becomes active.

There are multiple properties that may have changed, how would I go about updating them on the server? Additionally I'd like to provide an undo button so that the changes are reverted.

What I'm thinking of right now is to use the setters and check if the current value is the same as the changed value if there is a change then a request to a process in the background will be fired.

But I'm not sure this is the best approach and maybe setters with extra logic aren't the best practice. I think this is a problem that many web applications have to deal with and maybe there is a pattern that makes all of this more elegant.

It would be nice if someone could explain how they would solve this.

share|improve this question
Is there a Save button for each field or one button for all the fields? – superM Feb 27 '13 at 8:02
A single Save button for the entire row which models the Object. – nikhil Feb 27 '13 at 8:15
For saving data you could pass the changed data in the field-value format. And for undoing the changes, you could keep history of the values of the fields, and also changelists, so that you could determine that the fields were changed at the same time. – superM Feb 27 '13 at 8:22
up vote 3 down vote accepted

This strikes me as a borderline-SO question, but I'll answer here. I think you want to use the Command Pattern. Implementing that pattern gives you the structure required to support undo and even multi-level undo.

The easiest approach would be to have each "Save" press generate a Command object with the form's current values; when your processing code receives the command it can first "archive" the data object's current state to the command so that you can have a before/after picture of the data object and thereby support undo.

That approach is slightly hamfisted and could be improved by only recording the information of the properties that are actually changing. I'll leave it up to you to decide if it's worth adding that extra logic to essentially "diff" the field values, as it definitely adds an extra layer of bookkeeping.

I also suggest further reading in the somewhat-related Command-Query Separation principle. It's a very useful principle to follow in many areas of architecture.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.