Is IEditableObject Too Hard?
Everyone familiar with IEditableObject? Go read about it. I'll wait.
So by now you know that IEditableObject is an interface that gives you three methods: BeginEdit, EndEdit and CancelEdit. The idea is that before you bring up the editing UI for your object you call BeginEdit, and then if the user completes the edit you call EndEdit, but if they abandon the edit (presumably by clicking Cancel on a dialog) you call CancelEdit and the changes are "rolled back".
IEditableObject works really well when your user interface is modal. If you show a modal dialog in which the user makes changes, and force them to click OK or Cancel when they're done, you know exactly when to call the methods of IEditableObject and everything is peachy.
But many modern applications seem to have done away with dialogs. Vertigo's awesome Family.Show is a great example of a user interface that uses docked panels to edit content, and it generally does away with the "OK/Cancel" metaphor, instead using a single "Done" button. If I screw up while editing a person, I have to undo the changes myself.
Sure, there are a few places where Family.Show uses an OK and Cancel button pair, but they're mostly about creating new objects, where the "Cancel" action isn't rolling anything back - it's just not adding the new object to the collection.
I can totally see why you'd go down this route. The "docked panel" approach is just so nice-looking, and doesn't jar the user away from the safe haven of the main window. And if I'm in the editing process and realise I'm looking at the wrong object, there's no "cancel" - I just click on the object I did want to edit, and data binding takes care of everything for me.
So ... is IEditableObject dead? Does anyone use it any more? Are modal dialogs truly going the way of the dodo?
I don't have any answers. What do you think?
Comments
# Joe
6/06/2008 2:06 AM
We have eliminated the concept of Undo.
We are developing business applications (not CRUD apps) so our concerns may differ.
If I have a Widget that I am looking at, and I want to edit it, we us a different class.
Our WidgetBO is a business object. It is immutable, always valid, exposes nothing but a string for display identification, and public methods. If a UI needs to edit that widget it gets a WidgetDV (data view). It exposes its data so the UI can display all options. When the user makes change on the form and chooses 'Done', the UI calls a method on the WidgetDV class called, Validate. If it is valid the WidgetDV is passed to WidgetStorage along with the original one. If a user hits undo, then no call is made.
The result has been that are UI's and related CRUD code is much less buggy, much harder to mess up, and easy for the next guy to understand.
# Emmad
18/05/2017 1:06 AM
The concept of 'undo' using interface objects bound to a database is very hard to implement and keep consistent for a large project. A work-around may be to invoke a 'refresh' from the db. However this is just my opinion and be a generic solution. I know that IEditableObject does a shallow copy. Also it does not touch the data source, so if objects are bound, I am not sure how it would affect the data source. CSLA framework tried to address this issue in the past.