Hi,
I use Csla 3.6 vb for WinForms.
I want to use BindingSourceNode and BindingSourceHelper to manage Master-Details display but without using CslaActionExtender because I implement the Save button on a ToolBar (as Rocky wrote in his book).
I don’t want to use n-level undo but I don’t understand how to do that (not use n-level undo).
My BO inherits from BusinessBase which implements IEditableBusinessObject which implements ISupportUndo so my BO use always n-level undo.
In BindingSourceNode, there are such lines :
Dim root As Core.ISupportUndo = TryCast(objectToBind, Core.ISupportUndo)
If root IsNot Nothing Then
root.BeginEdit()
End If
So always my BO (objectToBind) use n-level undo.
How to not use n-level undo ?
Thanks for help
In your constructor you can set the DisableIEditableObject property to prevent data binding from interacting with n-level undo.
You must be aware that data binding expects the object to honor IEditableObject, but there are some scenarios where you can disable the behavior and still get a workable UI.
In other words, you are about to go down a road where you'll be fighting with data binding. If you fully understand how data binding works, and what it expects and what happens when it doesn't get what it expects, you can construct a UI that works with IEditableObject disabled.
I strongly recommend creating some very basic test apps with test scenarios to see what does and doesn't work, so you can learn the limits of this scenario.
Thanks Rocky for your answer.
I want to use the databinding with IEditableObjet.
I don’t understand why n-level undo is lied with databinding.
Databinding uses IEditableObjet (from framework). This interface has 3 methods : BeginEdit, CancelEdit and EndEdit.
N-level undo uses ISupportUndo (from Csla). This interface has 3 methods : BeginEdit, CancelEdit and ApplyEdit. Why do you use the same name for the methods BeginEdit and CancelEdit ?
Why there is not a flag DisabledUndo ?
With a such flag, we could disabled only undo and keep the databinding (and its IEditableObjet).
For instance, in the code inside BindingSourceNode :
Dim root As Core.ISupportUndo = TryCast(objectToBind, Core.ISupportUndo)
If root IsNot Nothing Then
root.BeginEdit()
End If
We could add :
Dim root As Core.ISupportUndo = TryCast(objectToBind, Core.ISupportUndo)
If not(DisabledUndo) and (root IsNot Nothing) Then
root.BeginEdit()
End If
It is sure, I can add it but I don’t want to change Csla.
Over more, I think that if you don’t do it, there is a good reason. Thanks to explain.
IEditableObject requires that the implementor (CSLA) take a snapshot of the object state when BeginEdit is called, so it can revert to that snapshot when CancelEdit is called. That is what n-level undo does, so CSLA uses its n-level undo behavior to implement IEditableObject.
Actual n-level undo is never used unless you invoke it. So there's no reason to have a flag to disable n-level undo, because that'd be ridiculous. N-level undo is never used unless you use it. So why would CSLA implement a flag so you can turn off a feature you explicitly wrote code to use?
If anything, CslaActionExtender might need a way to indicate that it shouldn't offer support for a top-level Cancel button. I actually thought it had that already, but perhaps not.
For example, look at the Csla.Xaml.ViewModelBase or Csla.Xaml.CslaDataProvider - both of which have a ManageObjectLifetime flag so you can indicate whether you want those components to automatically use n-level undo to make it possible for you to have a top-level Cancel button.
In other words, whether n-level undo is called (outside IEditableObject) is a UI concern, not an object concern. The only reason there's a flag to disable IEditableObject is that it is impossible to prevent Windows Forms from invoking that interface, so the object has to be able to ignore it to accomplish certain edge case scenarios in Windows Forms.
Thankfully all the modern UI technologies work much better with binding than Windows Forms, so eventually much of that stuff will be able to go away from CSLA (or so I hope).
So back to CslaActionExtender. If it doesn't have the equivalent to ManageObjectLifetime, it probably should. Unfortunately Windows Forms support in CSLA is in bug-fix-only mode. I view it as a legacy technology at this point - almost by necessity, since I can barely keep up with everything that's changing in the modern UI technologies,..
Of course CSLA is open source, so if you'd like to enhance CslaActionExtender along this line (and sign a contributor agreement), I am absolutely willing to consider accepting a patch along that line.
Thanks Rocky for your explanations.
In a few weeks, I hope to have a little of free time so I’ll see to do a patch and I shall send you.
Copyright (c) Marimer LLC