Binding to IsDirty on BusinessListBase in CSLALight
Binding to IsDirty on BusinessListBase in CSLALightOld forum URL: forums.lhotka.net/forums/t/8468.aspx
MarkOviedo posted on Wednesday, February 03, 2010I am writing a simple CRUD screen for application setup. I have derived my own ViewModelBase and ViewModelListBase from BusinessBase<> and BusinessListBase<> respectively, and am binding those directly to our XAML screens.
I would like to be able to bind the IsEnabled state of the Save and Cancel buttons to the ViewModelListBase.IsDirty property. In investigating BusinessListBase.IsDirty, it is clear that this value is only calculated on-demand.
My first question is : Is there an easy way to be notified of property changed for BusinessListBase IsDirty?
If not, my approach was going to be :
1) Override BusinessListBase.InsertItem. For each added item, subscribe the List parent to the OnPropertyChanged event of the child.
2) Override OnDeserialized on the client. Upon deserialization of the list parent, re-subscribe OnPropertyChanged for all children.
3) In the parent OnPropertyChanged handler, fire PropertyChanged("IsDirty").
Is there a better way to do this? Will these event subscriptions impact the serialization/deserialization of the mobile formatter?
RockfordLhotka replied on Wednesday, February 03, 2010
There are a couple solutions.
The simplest thing is to use a CslaDataProvider or ViewModelBase/ViewModel because these types already do all the work for you and expose auto-updating properties to make UI development easy.
Failing that, you'll need (for a general solution) to do what ViewModelBase (3.8.3) or CslaDataProvider do, which is to handle PropertyChanged, ChildChanged and CollectionChanged to universally detect when the underlying object graph has changed.
I don't recommend your approach - there may be unintended consequences of raising PropertyChanged for IsDirty (probably when binding to datagrid controls), and certainly hooking/unhooking all those events properly is non-trivial. Just look through the fun code that exists to make ChildChanged work - it is a serious PITA to get this right and not have nasty side effects.
Since we already did the work with ChildChanged, you are best off using that. But if it is your root object that changes, then you need PropertyChanged or CollectionChanged - which is why you need to handle all three to have a complete solution.
Copyright (c) Marimer LLC