DisableIEditableObject in Rolodex Example

Jack posted on Thursday, January 29, 2009

Is there a reason this is set to true?  The 2008 book recommends not setting it - is this a silverlight thing?  If so, why is it also in the private constructor?

If my plan was to have a Silverlight version and one or more non-Silverlight version is this something I should not be turning off?

I'm asking as I currently have my constuctors defined in my codeGen templates so it will come out in all classes.

Thanks

jack

sergeyb replied on Thursday, January 29, 2009

Jack replied on Thursday, January 29, 2009

rsbaker0 replied on Thursday, January 29, 2009

Just as an aside, I use DisableIEditableObject in my WinForms application, because evidently some elements of the UI design are unusual and are seemingly incompatible with the default binding implementation. (I'd do it differently and be compatible, but I lost that battle).

Anyway, turning IEditableObject off (DisableIEditableObject=true) means your objects will ignore all calls made via the IEditableObject interface, making you completely responsible for doing BeginEdit()/ApplyEdit()/CancelEdit() yourself.  You still have N-level undo capability, provided you implement it yourself by making these calls at the correct point in time.

My understanding from the forum here is that WPF and Silverlight are better behaved (more consistent?) in their handling of IEditableObject and that disabling it should rarely be necessary.

lukky replied on Thursday, January 29, 2009

Hi rsbaker,

I've started handling this myself in my winforms application too because the d*mn BindingSource would keep causing EditLevel errors.

As I already mentioned in another post, I wish there was some document somewhere that would detail the exact mechanism that the BindingSource when deciding to call IEditbaleObject's BeginEdit(). I've tried to trace it, and it seems that it's actually the CurrencyManager that does it, but it's over my head for now.

As you've probably noticed yourself, when you pass a BO as the BindingSource's DataSource, sometimes the BindingSource will call BeginEdit() on the BO, and sometimes not, and I've not been able to understand clearly the reason.

Do you maybe have some insight into this issue ? If so, please share

rsbaker0 replied on Thursday, January 29, 2009

I think most EditLevel errors can be avoided by using CSLA managed properties in 3.5 for child lists and BO's (the managed property infrastructure will set the edit level properly when a child BO is born while editing) and by properly unbinding the object, saving it, and rebinding the returned reference (search for RebindUI for examples).

The show stopper for me was that we have a ERLB side by side with a property sheet for the current object in the list. Once IEditableObject.BeginEdit() has been called, subsequent CopyState() aren't cascaded through the object graph to the BO descendants anymore, so my undo didn't work. There might be a solution, but I decided to take over the edit management myself and so far it's working OK.

Incidentally, once I disabled IEditableObject and doing my own BeginEdit(), I found all my EditLevel problems where I wasn't syncing up the edit level (this was before managed properties, and one of the main reasons I use them for child objects now).

lukky replied on Thursday, January 29, 2009

Actually, the EditLevel problems that I'm referring to did not come from Child Properties. I've only really started using CSLA with version 3.6, and I've used managed properties since day 1.

No, actually the problem was coming from the fact that I wanted to provide the user with a way to recover from errors happening during Save(). Basically, I would Clone() the BO before saving, and in case of exception being thrown, I'd rebind the cloned BO. At that time I was using the CSLA BindingSourceNode + BindingSourceHelper classes.

What happened is that sometimes when rebinding the object, the EditLevel would be raised by 2, and other times by 1. This of course caused problems when saving. All this hapenning on the Root BO, not children.

Maybe it's something to do with the helper classes, maybe not, but since I've been doing it manually, it's been working fine.

Funny stuff.

JoeFallon1 replied on Thursday, January 29, 2009

Luc,

"Basically, I would Clone() the BO before saving, and in case of exception being thrown, I'd rebind the cloned BO"

I hope you are aware that as of 3.5 Rocky clones the BO for you automatically on Save. Unless you configure AutoCloneOnUpdate=False in your config file. The default is now True.

I am not sure if this is part of the reason for your pain or not. I do not do much binding in Winforms. I have a Web app and do most things manually.

Joe

lukky replied on Thursday, January 29, 2009

Joe,

Yes, I know that Save() clones automatically, but the problem is that in order to Save, the EditLevel must be at 0. So, if an exception is thrown during the Save, there's no way for the user to cancel his changes.

By having a clone taken before calling ApplyEdit(), then I can offer the user to cancel the changes. Maybe I get this wrong, but the way I understand it, saving a BO "forces" to give up undo.

Of course, one could reload the BO. Is that maybe the usual way of handling this ?

Luc

ajj3085 replied on Friday, January 30, 2009

Joe, you still need to do a clone before saving, or your form level cancel will break because you'll have called ApplyEdit before calling the save.  So it's still a useful pattern.  The CslaDataProvider in Wpf does this for you automatically, but in the WinForms world you still need to do it yourself (I think.  CslaActionExtender may handle it... but I"ve not had a chance to check out that new component).

JoeFallon1 replied on Friday, January 30, 2009

Pages 304-312 of the new book discuss the CslaActionExtender. It is supposed to help simplify the complexity associated with binding.

I won't even *try* to summarize 8 pages of Rocky's book in a thread!

Check it out.

Joe