It has been quite a while since I blogged. Actually, I was just about to sit down to write this blog post about 7 weeks ago when my wife went into labor. Soon afterwards, she gave birth to our second child — a son named Eli Hecker Genisio. Needless to say, I have been neglecting blog for a while.
Previous to that, I had gotten to a place where I felt like I was ready to wrap up my experiments in using Ruby for ViewModels and Models. Here is what I would have written:
What Worked, What Didn’t?
Using Ruby as the primary logic and model platform for MVVM (Presenter Model) style apps in WPF was a ton of fun. It gave me the chance to learn Ruby pretty well (I’m still a hack, but who isn’t?) and got to use many of the more advanced topics such as meta programming and mix-ins. My ViewModel code was succinct and my model code was even more trivial once I employed the HTTParty gem. What was most fun (and likely my biggest take-away) was how wonderful writing tests using rspec was. All of my tests were written using rspec and I think I might start writing my C# tests using rspec in the future.
What didn’t work: The general coding workflow. Since there is no tooling support for IronRuby in VisualStudio 2010, it became a disjoined development effort. This was not completely bad, but things like debugging and deployment became difficult. I cringe when I think about deploying ruby gems with a Silverlight app. In addition ,the integration between .Net and IronRuby at runtime still needs work. For instance, defining anything but a trivial property in Ruby did not translate well into the .Net side. Also, WPF had difficulty binding to ruby strings. Some controls worked well, but some completely failed. I ended up writing a ValueConverter in WPF that called ToString() on the Ruby string in order to bind properly. Silverlight can’t even try to bind to a dynamic property, so that was even more difficult.
In all, I left feeling like the “goods” and “bads” canceled themselves out and I was stuck asking myself: “Why would I want to do this for real applications?”. My answer is: “Until there is good tooling support for IronRuby in Visual Studio (don’t hold your breath), this story probably doesn’t have any legs”.
The Playground – A Twitter Search App
With that, I’d like to document my playground in case anyone feels like running with it. I created a WPF Twitter Search application (the 2010 hello world) and hoste d the code on BitBucket. Once I built all of the mix-ins necessary to support automatic property notification and convention-based command creation (amongst others), I came up with a ViewModel which is (mostly) void of .Net integration issues that looks like this:
1. Notice that the very first thing I do is add the ViewModelSupport mixin. This provides the support for the magic that happens under the hood.
2. Immediately following, I use the declare_notifiable directive. This will create a property that will notify on change, using INotifyPropertyChanged in the .Net world. This was included with the mix-in.
3. The responses method (read-only property in .Net) is a NotifiableArray. This is a Ruby array I built that will send collection changed events to .Net.
4. The execute_search method uses the execute_ convention to generate an ICommand property named search that can be bound to in the view. This is what gets executed when the user presses the “Search Twitter” button. It goes off to Twitter (Twitter.search to be explained later) to search for the text entered into the search_text property. For each tweet that comes back, wrap it in a TweetViewModel (explained later) and put it into the responses collection. The View will update appropriately.
5. The map_commands line is a class method that tells Ruby to go map any methods named execute_* to command properties (*) that can be bound to by the view.
As for the individual TweetViewModel, it looks like this:
It uses HashExposer which is a mix-in I wrote that will find any items in the hash with the key declared with expose as a property. It is a very simple wrapper to allow for binding in the WPF view down to the individual tweet properties found in the hash. The hash that is passed in in the initializer is what these properties map to.
Finally, here is what the Twitter service looks like:
By using the HTTParty gem, I get to define what Twitter.search(text) looks like in a minimal way. The response of search is a parsed hash which I wrap with the TweetViewModel. This is an AMAZINGLY simple way to consume web services in Ruby. I was shocked to see how easy it was.
That is everything on the Ruby side! All of the application-specific ruby code has been shown in this blog post. By using the ViewModelSupport mix-in (found in the source code), the rest of the .Net integration is abstracted away. With this alone, I felt like I was successful.
Next, I’d like to show the WPF side of the application. This is what the view looks like:
Just as in any MVVM application, all of the connections between the View and the ViewModel happen through binding. This is no exception.
The only C# in this entire application are in the bootstrapping of the ruby classes (ViewModelLocator) and the StringConverter which helps bind the view to Ruby strings.
The code for these support classes can be found in the source code on BitBucket.
This puts to rest my Ruby-based MVVM experiments. I learned a ton and I think there is a good foundation here for improvement if anyone wants to run with it.
For me, I will be moving on to some posts about Flex and ActionScript – another learning project for me to experiment with. Stay tuned :)