I'm trying to use CSLA with Prism and I'm running into an odd problem. Everything seems to work, I can retrieve entities ok and display them without problem, however if I link a button's is enabled property to CanSave or CanCancel, the button is never enabled.
I'm guessing that for some reason when a user makes a change to a field, the change event never makes back to the viewmodel ??
Does anybody have CSLA 4.1 working with Prism 4.0 ?
Can anybody give me some suggestions as to what might be going on with any of the CanXXX methods ?
Any help would be appreciated
Thanks
Terry
Hi,
CanSave, CanCancel properties do not raise PropertyHasChanged event and will not work properly with databinding.
You should create a ViewModel and wrap these Properties in your VM as properties with PropertyChangedEvent.
You may be able to use the default Csla.Xaml.ViewModel<T> or Csla.Xaml.ViewModelBase<T> or create your own class that inherits from ViewModelBase<T>.
I think Jonny's answer may cause confusion, Jonny will correct me if I'm wrong...
CanSave, CanCancel are properties of the ViewModel<T> and they *do* raise the PropertyHasChanged event of the *ViewModel* when the Model is a Csla editable object.
It is the meta properties of the Csla Model (IsSavable, IsValid etc) that do not raise the PropertyHasChanged event.
It looks to me like you are already using ViewModel<T> are you refer to the CanXXX methods. The only obvious thing I can think of is to check the datacontext of your command buttons is the ViewModel, as opposed to the datcontext of your edit controls which will be the ViewModel.Model
I don't think this issue is related to your use of Prism.
Peran
Peran
You are correct I'm already using ViewModel<T> and the datacontext of the command buttons are already bound to the ViewModel.
Does anybody have an example of a view that uses a ViewModel<T> viewmodel ?
Try putting a breakpoint in ViewModelBase<T>.SetProperties(). This should give you an indication of why your CanXXX methods are being set to false.
Peran
Hi Peran,
Yes, you are correct and I totally mixed up the Is... and Can... methods. Sorry folks.
Keep in mind that Csla.Xaml includes ViewModelBase<T> and ViewModel<T>.
ViewModel<T> is intended only for use with the other types in Csla.Xaml. If you use a UI framework like Prism, you should create your own ViewModel<T> based on ViewModelBase<T> - and your ViewModel<T> should expose public members designed to work with your UI framework.
The Csla.Xaml.ViewModel<T> has public members designed to work with TriggerAction. They won't work with commanding or other technologies, and so become noise if you don't use TriggerAction.
The few public members of ViewModelBase<T> should be universally valuable. By creating your own custom ViewModel<T> you can implement your own public members that conform to the requirements of your UI framework (whether that be based on commanding, Blend event triggers, or whatever).
Copyright (c) Marimer LLC