3 ms·

Undo Made Easy With Ajax

13 points by Bluem00 19y ago

Bluem00 19y ago
This article had a strong positive impression on my development team. If you like it, I recommend the other article it mentions at the beginning.
edw519 19y ago
This approach is too simplistic to be useful in a multi-user environment. Adds, changes, and deletes MUST be done immediately and cannot be queued without bottlenecking the entire system. Undo's MUST be examined for every possible ramification. What if you change something and then want to undo it AFTER someone else has changed it again? What if you want to undo an add after someone else has already changed it? What about undoing a delete after someone else has added it anew? Also, distinction must be made on how to handle a client side undo (simple) versus a server side undo (could be complex). I agree with the writer that undo is a necessity, not a luxury, in a serious web app. For industrial strength apps, however, more thought is needed than what this writer has provided.
- boucher 19y ago
  This approach is too simplistic to be useful in nearly any environment. On top of that, its basically the exact opposite of what undo is/has always been. The "correct" way to do undo, is to perform an event, and keep a list of inverse events. As you pop those off the undo stack, you can simply execute them. As you mentioned, this may be slightly more complicated in a multi-user environment -- but in this example, it would absolutely be the right way to go. Plus, this is so easy to get working in javascript, where you can actually push functions to the stack, and then execute them when you pop them off...
downer 19y ago
I recall this being lambasted on Reddit a while back: http://programming.reddit.com/info/2piup/comments http://programming.reddit.com/info/2piup/comments
- edw519 19y ago
  Thanks for that reference. 2 things about it enlightened me: 1. Hacker news is not the only place to read stuff like this. (although, for me, it sure seems that way now) 2. The children haven't made it here yet. (and hopefully they'll stay where they are)

13 points by Bluem00 19y ago

This article had a strong positive impression on my development team. If you like it, I recommend the other article it mentions at the beginning.

edw519 19y ago

This approach is too simplistic to be useful in a multi-user environment. Adds, changes, and deletes MUST be done immediately and cannot be queued without bottlenecking the entire system. Undo's MUST be examined for every possible ramification. What if you change something and then want to undo it AFTER someone else has changed it again? What if you want to undo an add after someone else has already changed it? What about undoing a delete after someone else has added it anew? Also, distinction must be made on how to handle a client side undo (simple) versus a server side undo (could be complex). I agree with the writer that undo is a necessity, not a luxury, in a serious web app. For industrial strength apps, however, more thought is needed than what this writer has provided.

boucher 19y ago
This approach is too simplistic to be useful in nearly any environment. On top of that, its basically the exact opposite of what undo is/has always been. The "correct" way to do undo, is to perform an event, and keep a list of inverse events. As you pop those off the undo stack, you can simply execute them. As you mentioned, this may be slightly more complicated in a multi-user environment -- but in this example, it would absolutely be the right way to go. Plus, this is so easy to get working in javascript, where you can actually push functions to the stack, and then execute them when you pop them off...

downer 19y ago

I recall this being lambasted on Reddit a while back: http://programming.reddit.com/info/2piup/comments http://programming.reddit.com/info/2piup/comments

edw519 19y ago
Thanks for that reference. 2 things about it enlightened me: 1. Hacker news is not the only place to read stuff like this. (although, for me, it sure seems that way now) 2. The children haven't made it here yet. (and hopefully they'll stay where they are)