Silverlight and Ruby on the Mac, Part 1: Hello Ruby

Ingredients you're going to need before following along with this blog post:

• Mono (latest stable release) for Mac OS X
• Silverlight 2.0 Plugin for Firefox (you can download this from http://www.silverlight.net ) 
• Silverlight Dynamic Languages SDK (You can download this from CodePlex )

Don't worry if the dynamic languages SDK seems like it's a windows-only download. Things are going to get really interesting during this post, and there will be some really, really blurry cross-platform lines... especially when we start busting out the Mono.

Hello Ruby

I have been listening to a lot of people tell me that I should be using Ruby for my Silverlight development because the dynamic language dramatically simplifies common development tasks and that my Silverlight applications will be quicker to market, cooler, more elegant, and indeed will sprout their own halos and emit solid gold from their debuggers. Not being one to believe anything anybody tells me, this series of blog posts is all about me trying to determine for myself if any of this prattle about Ruby and Silverlight being the holy grail is true. The first step in any evaluation of a new technology for me is the Hello World app. So this is how to build a Hello Ruby application using Silverlight and nothing but a Mac running Leopard... NO Windows machines.

Environment Setup

After installing Mono and the SDL SDK, its time to get rockin'. The SDL SDK comes with a shell script that will generate an empty Silverlight Ruby application in the directory of your choice. To do this, I dropped into Terminal in the SDK directory and issued the following command:

script/sl ruby hello

This created a new directory called hello that contained an index.html to host my Silverlight control, some stylesheets for reporting errors in specific divs, and of course a directory called ruby that contains all the good stuff.

Once I've got this directory set up, I change into the hello/ruby directory and I edit the App.xaml file and the App.rb file. The following image is a screenshot of me editing the App.xaml file:

And this is a screenshot of me editing the App.rb file:

Keep in mind that I'm not using a Windows machine to do any of this, nor have I invoked anything mono-related yet. Also worth noting is the classic Ruby syntax where I'm defining an event handler for the Click event on my button. One main difference between building C# Silverlight apps and Dynamic Silverlight apps is that the Xaml parser does not know ahead of time about dynamic classes and so cannot rig events directly in Xaml. My guess is that this also means I'm not going to be able to use ObjectDataSources with Ruby objects, but that's a topic for another post.

The next thing we need is a XAP file. A Xap file is basically a ZIP file that contains your Xaml, your Ruby, and all of your dependent DLLs and resources. When you hit a website that is hosting a Silverlight control, the plugin fetches the Xap file, cracks it open, and then starts running code in the client-side sandbox using what it found in the XAP.

This is where mono comes in. The SDL SDK comes with a tool called Chiron (that's pronounced KAI-RON in case you're curious). This tool can either run a web server that dynamically generates a XAP from the contents of a directory, or it can produce a static XAP that you can then use to deploy your control. For debugging and testing purposes, running the web server is a great option because you can see changes you make just by refreshing the browser.

To run Chiron, I simply changed to the hello directory and ran ../script/server /w (Chiron in web server mode defaulting to the current directory). Worth noting here is that Chiron.exe is a Windows-compiled application, but because it makes use of System.Net it can be invoked flawlessly using mono. In fact, when you run the server script, it is actually invoking Mono to run Chiron.exe. Here's a screenshot of me hitting the Chiron-hosted website using Firefox (again, this is all on the Mac):

So what's really going on here??

Basically what's happening is that when my client (Firefox on Leopard in this case) hits a web page that is hosting a Silverlight 2.0 control, the plug-in downloads the appropriate XAP file and then begins executing. It uses traditional Silverlight CLR code to create an instance of the DLR host that is appropriate for the language it discovered I'm using. In this case, it's going to use the Silverlight CLR to create an instance of the Ruby DLR host. From that point afterward, the Ruby DLR host is in charge and I'm now running Ruby code in the DLR, which is inside the Silverlight-CLR, which is inside the browser plug-in sandbox provided by Firefox.

Verdict

So far so good. I can use my favorite text editor to create Ruby files that are powering my Silverlight app and still have my Xaml so that I can still make use of Expression Blend (yes, I'd have to use Windows for this) to do up my GUIs. My next test will be to see if I can data bind a Silverlight Xaml GUI to Ruby objects. I'll cover my attempt to get that working in my next blog post.

tags: silverlight  ruby  microsoft  mac  apple  mono  chiron  dsl  dynamicsilverlight  

links: digg this    del.icio.us    technorati    reddit