A letter to the editor – Do you even READ the internets? More IronRuby and WPF

work safe

I’m writing this in response to a recent post I wrote on my website, A Ruby Cast In Steel. While I appreciated the insight my experiments gave me into both IronRuby and WPF, the author ended up with a few conclusions I’d like me to revisit.

Data Binding

You implied that Data Binding IronRuby is broken. This is untrue as noted by both members of the IronPython team and the IronRuby team. As you can see here, WPF Data Binding relies on the ICustomDataDefinition, which IronRuby objects implement. Building on the xaml tools I developed last time, here is an example of Data Binding at work.

I would have updated the xaml tools to use load_assembly instead of strong names, but strong names are the only thing that work on my Win7 box. This is nicely outlined in the IronRuby tutorials that come with the distribution. I might try them. I could learn a lot.

Combining Classes and Xaml

I found an article about combining an IronRuby class with xaml. However, this example was suitable for Silverlight 1.0 (look at the control box) and doesn’t work for me. I’ve examined the new Application api that’s suitable for 3.5, but I’m not able to generate a suitable Uri for the file. The Uri needs to be relative, not absolute, and the pack: Uris didn’t seem to work, probably due to a fundamental misunderstanding on my part.

Looking at the other side, I’ve not yet found a way to force an IronRuby class out of the engine into the CLR proper, the x:Class should work just find with an existing CLR class.

More importantly, code-behind is a compromise. Not even a good one at that. The development style I used was perfectly acceptable for utility style applications, but larger applications should have a complete divorce between the view and the rest of the code, connected only by binding. By introducing code-behind into the equation, I’m letting the rest of my application infect my view, coupling it tightly.

To be fair, my last post was written using IronRuby 0.9, and due to the ICommand interface implementing an event, you’ll need a more recent build.

In summary, The concerns for writing WPF apps in IronRuby at the end of my last post have been addressed or made redundant, with out pulling my favorite fear-mongering golden hammer and resorting to Code-Dom.

Thank me for my time,

On a more serious note, I’ve learned a lot this past week, with a little bit of the googles and the tutorials. I think I can start writing a “REAL” application in IronRuby, at least as a prototype. The remaining question is which itch am I going to scratch?

1 Comment

1 Comment

  1. Shawn Hoover  •  Aug 27, 2009 @2:43 pm

    Thanks for writing this pair of posts. They provide a nice solution for IronRuby as is and clearly enumerate the issues a would-be ClojureCLR/WPF developer would face as well.

    At first I was lamenting that “{Binding Path=my_command}” has to be a string… oh wait, it’s a string in XAML too!

Leave a Reply

You must be logged in to post a comment.