IEditableObject vs ISupportUndo

rxelizondo posted on Thursday, November 05, 2009

Sorry for taking the easy way out and ask the question rather than try to research the answer to it but :)

IEditableObject and ISupportUndo appears to be designed to accomplish the same thing so I can’t help but wonder why the need to create ISupportUndo when IEditableObject already exists and it’s used throughout the CSLA? Was the ISupportUndo created to support a different kind of context?

Thanks.

RockfordLhotka replied on Thursday, November 05, 2009

IEditableObject is defined by and owned by Microsoft. CSLA must implement IEO exactly like the DataTable or data binding won't work correctly in Silverlight, Windows Forms or with decent WPF (apparently non-Microsoft) datagrid controls.

I needed a polymorphic way to access n-level undo from the UI level, specifically when we started creating the CslaDataProvider controls, and more recently with the MVVM support. And I needed to access it in a way that wasn't constrained by the rules around IEO.

rxelizondo replied on Thursday, November 05, 2009

Thank you.

Just out of curiosity, since the CSLA uses ISupportUndo for its own unique needs, should we remove the “internal” access to the following methods to force other classes on the framework to go directly through the ISupportUndo interface?

protected internal void CopyState(int parentEditLevel)
protected internal void UndoChanges(int parentEditLevel)
protected internal void AcceptChanges(int parentEditLevel)

I realize that it is not strictly necessary but I think it would formalize what you are trying to achieve with the ISupportUndo interface.

Just a call out, again, I may be totally off the mark here as usual. But if they are not meant to be used as internal methods is best to formalize that idea, no point on having people wonder why is it internal.

RockfordLhotka replied on Thursday, November 05, 2009

If I had unlimited time and energy, sure :)

rxelizondo replied on Thursday, November 05, 2009

Ok, I will give you a break and stop bugging you with this non sense posts.

Just one more request, the “UnduableBase” has a “Helper Functions” region and I don’t think these functions are needed there.

The “NotUndoableField” is implemented in the “UndoableHandler” and I think the “GetFieldName” method is now obsolete with all the other changes you made to the state code... (I think).

by the way, I would be more than happy to do all these changes for you if you let me but I have a feeling you would't want to take that risk :)