4 ms·

In a traditional 'desktop style' app simply ported to the web this may be possible. But in a multi-user app that may not be the case. What if the record you d

by aquark 13y ago

In a traditional 'desktop style' app simply ported to the web this may be possible. But in a multi-user app that may not be the case. What if the record you deleted was subject to some kind of uniqueness constraint. If another user has added a record that has the same data, then flipping the delete flag off again would not violate that constraint. Sure, it could be handled by checking if the constraint is violated. but you rapidly run into a lot of code to implement that one feature and dealing with thinking of and testing all the edge conditions makes it much easier (& cheaper) to focus on other features.

smooj 13y ago
I think those constraints are often the same as when you create a new record, so you can reuse code from there. But I'm sure there can be edge cases that make it tricky for some apps and/or situations. Undo and redo aren't important features for every web app - in some they would't make sense at all - but for applications that facilitate any kind of creative process, such as photo editing, 3d modeling, or drawing, they are very important features to include. Users often want to try out an idea, then go back to an earlier version if the idea doesn't work out. In most cases for apps like these implementing undo/redo gives you a ton of usability bang for your proverbial buck.
kika 13y ago
I just went through it, it is actually difficult, but not THAT difficult. You don't flip a flag, you implement a Command pattern of sorts: instead of deleting an object you record the command "DELETE" along with the copy of the object. When you want to undo delete, you take this record, change "DELETE" to "CREATE" and submit this command to execution. Then all the constraint logic works as if you're creating the object from scratch, with possible conflict resolution along the way. Undo is easier if it's not an implementation of time travel but redoing something you did previously in the opposite direction.

by aquark 13y ago

smooj 13y ago

I think those constraints are often the same as when you create a new record, so you can reuse code from there. But I'm sure there can be edge cases that make it tricky for some apps and/or situations. Undo and redo aren't important features for every web app - in some they would't make sense at all - but for applications that facilitate any kind of creative process, such as photo editing, 3d modeling, or drawing, they are very important features to include. Users often want to try out an idea, then go back to an earlier version if the idea doesn't work out. In most cases for apps like these implementing undo/redo gives you a ton of usability bang for your proverbial buck.

kika 13y ago

I just went through it, it is actually difficult, but not THAT difficult. You don't flip a flag, you implement a Command pattern of sorts: instead of deleting an object you record the command "DELETE" along with the copy of the object. When you want to undo delete, you take this record, change "DELETE" to "CREATE" and submit this command to execution. Then all the constraint logic works as if you're creating the object from scratch, with possible conflict resolution along the way. Undo is easier if it's not an implementation of time travel but redoing something you did previously in the opposite direction.