Caliburn.Micro and "Blendability"

Mar 27, 2011 at 9:54 PM

Before I started using CM, I had been learning the MVVM Light framework. I am thoroughly enjoying Caliburn, but one thing I do miss from working with MVVM Light is the ability to use Blend's sample data feature to get a better view of what the application looks like at design time. You could set a design-time data context, and Blend would populate your bound fields with data from a sample data file.

It seems like CM's conventions-based approach means this isn't possible, since the bindings get created at run time. In many cases I'm able to just put sample text directly into the text property, since any hardcoded text will be overwritten when the app runs.

But in other cases, such as when I'm manually binding a text property for some reason (when using a value converter, for instance), it doesn't seem possible to have design-time data, as the binding information goes in the Text field. The same goes for using conventions to bind lists to ListBoxes.

I'm sure I could cobble together solutions to these specific problems, but CM is so full featured in other areas that I can't help but wonder if I'm missing something. Is there a general strategy for binding sample data in CM projects?

If not, the productivity gains from CM still make it a worthwhile tradeoff. Just hoping I can have it all. :)

Thanks,

Josh

Coordinator
Mar 27, 2011 at 11:21 PM

Unfortunately, you know all there is to know. I've tried to explain these scenarios to the Blend team so that we can get the proper extensibility hooks in the product to make conventions work at design-time, but they just have a hard time understanding. They don't follow up on things and they are a very "closed" group inside or Microsoft. Silverlight and WPF MVPs don't necessarily have direct access to them. You have to be a Blend MVP. Those tend to be mostly designers and very few who understand larger scale development or even the benefits that conventions can give on simple projects. Doing this *might* be possible, but it would require a lot of very painful work and would probably break with the next release of Blend. The APIs for extensibility that are there are not very well documented. Then, there's also the issue of making it work in Visual Studio as well. Currently, I don't have the time or patience to try to come up with something. It's a great place where a contribution from the community would make a massive difference. I'm going to keep bugging the Blend team when I can. But, my guess is that they have other concerns.

Mar 27, 2011 at 11:41 PM

Thanks, Rob. I thought that was the case but wanted to be sure. Given the productivity gains I'm getting with CM, a little extra design effort is worthwhile. I've been having good results with doing rough design first with some hardcoded ListBox items, then applying conventions once I have the templates set up. Caliburn.Micro + Blend would be an amazing combination, though. We can dream...

Mar 28, 2011 at 2:07 AM

I've been using Caliburn Micro and Blend together for a fair while now, I don't tend to make use of the conventions for binding for the reasons listed above. I find the conventions around actions to be the real productivity gains.

These days my workflow is

  1. Outline the view model in terms of data exposed as properties and bindable collections.
  2. Outline the view model actions as methods with NotImplementedExceptions.
  3. Create unit tests for the view model.
  4. Implement view model actions to get unit tests passing
  5. Create sample data based off the view model in Blend.
  6. Bind the view to the sample data, this is the annoying part, but I don't find it too cumbersome.
  7. Complete the view including naming certain elements to make use of caliburns action conventions.
Mar 28, 2011 at 11:52 PM

Good stuff, Nigel. I might have to give this workflow a go next time around.

One thing that I'm finding interesting is that I got into MVVM to try to make my apps more testable, but CM is getting rid of a lot of code, and the tricky bits that are left are inherently untestable (i.e. databinding, converters, etc.) My current app is pretty simple, really, so maybe CM is just exposing how little business logic was hiding under all of that plumbing code.