You have a form that has an object injected into it. The user interacts with the form and updates the injected object via the UI. If the user then 'Cancels' the form, whose responsibility is it to undo those changes?

Should the form have created a clone of the object passed in, and return that to the client? Or should the client watch for the 'Cancel' action and perform the undo action?

Is there a 'best practice' for this?


Ideally, the UI shouldn't know about your business objects directly. It should know what it has to display and where to send any submission. The receiver of the submission should know how to process that submitted data with respect to your domain objects.

Thus there should be nothing to roll back, only form data to be discarded.

Sometimes you have to store form data somewhere, in case the submission is put on hold, or the application crashes, or whatever. In those cases, I would still suggest storing form data separately from domain data, making it just as easy to discard.

In the rare occasion where you might need to apply data changes and test it before rolling it back. If you absolutely can't use a staging area then use soft-deleting and history records, but definitely don't expose that to the UI. Only allow it to switch between revisions.

  • So, instead of the UI being passed ComplexFooObject, and then extracting data from that to display (for example timepoints), it should just be passed a list of timepoints, and when they change, maybe have an event to handle this? Thanks – Darren Young Feb 6 '14 at 15:48
  • @DarrenYoung: It should be passed whatever it needs to display. If you were thinking about a Cancel button then I assume the underlying application knows at what point it would roll back to, on cancellation. If that's the case then you need only pass the current state to the form; hitting the cancel button would tell the application to discard any changes since the last confirmation and then reload the current state. – pdr Feb 6 '14 at 15:57
  • thanks. That's the functionality that I was trying to reconcile; should the form roll back of the underlying application. I think you've answered my question. Thanks. – Darren Young Feb 6 '14 at 15:59

If I am following correctly, you have clicked the save button, but then want the ability to discard those changes almost straight away.

There is a further complication here which may be that before hitting the cancel button, the user might make another change and hit Save.

So it could be the case that you store a history of the object in the database, track a "last version ID" and use that on Cancel postback to restore the last version.

  • There is an OK button and a Cancel button. If the user presses OK, any changes are persisted, it the user presses Cancel all changes are discarded. – Darren Young Feb 6 '14 at 15:49
  • that's a much more simpler case then. the answer is, nothing happens, the object is simply discarded. There are no changes to undo as they have not been persisted. – ozz Feb 6 '14 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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