I'm still working on my Caliburn prototype with the CSLA.NET and I have encoutered a small limitation. All properties from ITrackStatus are defined as regular property instead of Business Property which can be binded to a XAML control properties. I beleive the IsDirty and IsValid at least should be converted to bindable property. They are of great help for enablin or desabling Save or Cancel button.
Any comment on this?
I don't know how Caliburn works, but typically these properties are exposed by the viewmodel as UI bindable properties.
Remember that CSLA supports not only XAML, but also Windows Forms, Web Forms, ASP.NET MVC and other interface technologies. So it is important to keep the base class properties pretty basic so they work across all those different technologies. Right now the big limiting factor for most things is Windows Forms, but so many people use Windows Forms that I couldn't drop support for that technology in CSLA 4. (though I sure hope I can drop it for CSLA 5!!)
XAML isn't the only UI technology that needs helpers though. There are helpers for Windows Forms and Web Forms and MVC, as well as for SL/WPF - and by "helpers" I mean objects that convert simple properties into something that can be easily consumed by the specific UI technology.
You can look at what I've done for ViewModelBase<T> and CslaDataProvider and PropertyStatus to get some very good ideas about how to convert the simple CSLA object properties into XAML-friendly properties.
Unless Caliburn does something unconventional, you likely need a single bindable property, so IsDirty and IsValid aren't very directly useful for xaml binding anyway.
That being said, Rocky, isn't an IsSaveable property in the business object itself that combines IsDirty, IsValid and Authorization something still below the line of any specific interface technology? (As I recall, that's one of the extensions I added at a prior job for use in WinForms.)
IsSavable is on BusinessBase, yes.
The thing is, all those metastate properties are implemented to not interfere with Windows Forms binding - which means they don't raise PropertyChanged and aren't bindable (they are Browsable(false)). That also allows their implementation to be passive, which is good for performance in some cases.
At some point, when I drop Windows Forms support probably, I'll rework those metastate properties to have active implementations and to raise PropertyChanged as they change. They'll still be Browsable(false), but for most UI technologies that doesn't block binding, it just hides them from automatically being added by the VS designers.
Copyright (c) Marimer LLC