Using Caliburn.Micro with CSLA

Jul 14, 2010 at 10:23 AM
Hi, I wish to adopt Caliburn.Micro, but we are using CSLA for our business objects. As CSLA uses a rich (rather than an anemic) model paradigm, we bind to the model properties directly from the views. In other words, we use a variation of CSLA's ViewModelBase which contains a 'Model' dp which is the business object containing the properties we bind to. How does Caliburn.Micro cope with recursive implicit binding? Is this something we can extend? How would be the control naming syntax? TIA.
Jul 14, 2010 at 12:59 PM

Can you explain what you mean by "recursive implicit binding"?

Jul 14, 2010 at 1:37 PM
Hi Rob, essentially I want to implicitly bind (using control naming conventions) to a property sitting on a 'Model' property sitting on the view model. E.g. if I have a 'Person' CSLA business object with a 'Name' property, that Person class is the 'Model' property on my view model. So I would want to do something like this in my XAML: <TextBox x:Name="Model_Name" /> and this would bind to the Name property on the Model property on the current data context (my view model)
Jul 14, 2010 at 7:14 PM

Currently Caliburn.Micro does not support what you describe. It is supported in the full version of Caliburn though; using exactly the convention you demonstrate. If you want to implement this yourself, you will have to replace the ViewModelBinder.Bind method with your own implementation. I'll take a look and see what it would take to support this out of the box. If I can do it will a small amount of code, I will go ahead and add promises though.

Jul 15, 2010 at 7:55 AM
Rob, it seems like the idea of recipes would be good for things like this one (as in a tiny sample project with a derived ViewModelBinder and a usage V+VM). Maybe you could use a promotion process (voting? nagging? begging?) to fold wildly popular recipes into the ever-slender CaliburnMicro code base. Seems like these recipes could live as a peer to the common samples. Just a thought.
Jul 15, 2010 at 1:37 PM

That's a good idea. I was thinking of having a sort of community recipes part of the site eventually. Right now I'm trying to pump out the core documentation (which takes a while) and fix any bugs or get last-minute critical features in. But, I could interleave a few typical "recipes" into the mix such as customizing the ViewModelBinder, ViewLocator and Conventions which I assume will be the areas people want to alter the most.

Jul 21, 2010 at 6:58 AM

I'm also using CSLA and this would be something I would love to see.  I've been doing way too much of :


Property XYZ {get {return Model.XYZ;}}

or in my View: Binding={Model.ChildModel.XYZ;}


Would it be possible/simple to add a convention that if it found a type of CSLA.ViewModel<T> named Model it then modified the attached binding as Model.XYZ ??  But then you run into another implementation of IsBusy on the CSLA model and all the CanXyz etc.

Anyhow, I'm super pumped on this framework.  I've gone full circle from nothing, to Prism, I actually looked at Calibourn way back in beta, then settled on SilverlightFx, then tried to use part of CSLA, and now I have a horrible mess.  I'm convinced this is the solution, just a matter now of working and refactoring to get it into my Production app.


Jul 21, 2010 at 1:19 PM

You could certainly customize the framework to enable your scenario. I'll add a ticket to improve the extensibility of the ViewModelBinder so that it's easier for you. Right now you have to replace a lot of functionality to plug in what you want. I'll try to make that easier.

Jul 22, 2010 at 6:14 PM
Edited Jul 22, 2010 at 6:16 PM

Perhaps it could just be a simple way to add a list of types that should be processed recursively and a naming convention.  Then it is a simple change to the ModelBinder to add a recursive loop rather than call some external method that ends up replicating the same exact logic.


AddRecursiveBindingType(typeof(CSLAViewModel<T>), '_')

AddRecursiveBindingType(typeof(SomeChildModelClass), '_')

Then it would take any property derived from the CSLA base class and scan it for public properties binding them to controls name as TypeName + '_' + TypeName.PublicProperty to TypeName.PublicProperty.

So it would pickup ViewModel.childModel.SomeProperty  and bind as childModel_someProperty when the visual element was named ChildModel_SomeProperty

instead of adding a type and maintaining a list of types (more app generic) you could add a [RecursiveBindingProperty] attribute on the property to be processed recurively. 

The reverse, [SkipRecursiveBinding], could be used in conjuction with the first option to optimize what not to scan for extra bindable properties.


Aug 22, 2010 at 3:13 PM

Hi Rob, has there been any progress with this?

Aug 23, 2010 at 2:47 AM

Unfortunately, I haven't had time to work on this yet. I've been buried. I have it in the list of issues and I "think" I can make this work for bindings. It's pretty high priority in my mind since it would greatly expand the supported scenarios. I just haven't got around to it yet...After next weekend I should have some more time. So I'm going to try to knock out the remaining tickets then.

Aug 23, 2010 at 2:53 PM

Great, thanks Rob!

Jan 26, 2011 at 11:07 PM

Hi Csla people that found this thread,

Please note this was fixed on change set 470e7c544d06 by EisenbergEffect Sep 14 2010 at 3:46 PM
-Enabled complex binding paths for convention binding. You can now do this:
<TextBox x:Name="Customer_FirstName" />
The convention mechanism will now look for matches on N-level child objects based on name. Names are case-insensitive. If they have a preceding underscore, that will now be stripped out.
-Made some minor internal refactorings to the convention binding APIs to acommodate the above improvement. 

Tiago Freitas Leal