Everything I’m about to talk about is currently in the master tree of the ninject github repository.  Getting IronRuby to play nice with Ninject was surprisingly easy :),

There was only one place that required some kind of weird workaround and from that workaround I’m entirely sure that it will go away by the time .NET 4.0 will be here.  The DLR duplicates a number of delegates from .NET 4.0 but .NET 3.5 also defines them (i.e. System.Func<T, TT>) and then you get great exception messages like: System.Func is not of type System.Func. The solution is to not reference System.Core in your project. Except that Ninject expects the System.Core variant at some point and that was solved by aliasing the System.Core assembly and talking to the types in that assembly by their alias.

Anyway the juicy stuff :) How can you take advantage of Ninjects newly found friendship with IronRuby.

Ninject now has 2 flavors of Kernels. We have a StandardKernel that knows how to deal with the module configuration system that uses a fluent interface defined in C#.  And now we also have a DlrKernel that extends the StandardKernel with a RubyModuleLoader plugin. If you tell the DlrKernel to look inside a path for configuration files it will scan those folders for *.dll or *.rb files. Those files should contain the configuration for the ninject bindings.

So to create a Kernel that is ruby enabled you would use the following code:

IKernel kernel = new DlrKernel();
kernel.AutoLoadModulesRecursively();

var samurai = kernel.Get<IWarrior>();
System.Console.WriteLine(samurai.Weapon.Name);

The above snippet could then for example load a configuration file that has been defined like this:

require File.dirname(__FILE__) + '/../Ninject.Tests.dll'
include Ninject::Tests::Fakes

to_configure_ninject do |ninject|
  ninject.bind IWeapon, :to => Sword
  ninject.bind IWarrior, :to => Samurai
end

The configuration above shows how most of a typical configuration would be defined by you the full configuration API at your disposal. All the options for the configuration can be specified in 2 ways. The first way is in a hash like syntax and the second way uses a more fluent syntax.

to_configure_ninject do |ninject|
ninject.bind IServiceA, :to => ServiceA, :as => :singleton,
:meta => { :type => "superservice" },
:name => "aaaaa",
:with => {
:parameter => { :my_param => lambda { |context| "param_value" } },
:constructor_arguments => {:const_arg => 56 },
:property_values => {:property_name => 94 },
},
:on_activation => lambda { |obj| obj.do_some_work },
:on_deativated => lambda { |obj| obj.do_some_cleanup },
:when => lambda { |context| "a value" } or
:when => { :injected_into => ServiceB } or
:when => { :target_has => AnAttribute } or
:when => { :member_has => AnAttribute } or
:when => { :class_has => AnAttribute }
}
end

Or

to_configure_ninject do |ninject|
ninject.bind IServiceA, :to => ServiceA, :as => :singleton do
meta :type => "superservice"
name "aaaaa"
with :parameter => { :my_param => lambda { |context| "param_value" } }
with :constructor_arguments => { :const_arg => 56 }
with :property_values => { property_name => 94 }
on_activation do |obj|
obj.do_some_work
end
on_deativation { |obj| obj.do_some_cleanup }
condition do |context|
true
end or
condition :injected_into => SomeClass or ...
end
end

Some of the nicer consequences of using Ruby as a configuration language is the syntax for open generics. The example below shows how to configure types with open generics.

require File.dirname(__FILE__) + '/../Ninject.Tests.dll'
include Ninject::Tests::Fakes
include Ninject::Tests::Integration::StandardKernelTests

# IGeneric is a generic interface and GenericService is a generic type
# we don't have to specify any special notation for open generics

to_configure_ninject do |ninject|
  ninject.bind IGeneric, :to => GenericService, :as => :transient 
  ninject.bind IGeneric, :to => GenericService2
end

To specify a condition the syntax would look like this

require File.dirname(__FILE__) + '/../Ninject.Tests.dll'
include Ninject::Tests::Fakes

to_configure_ninject do |ninject|
  ninject.bind IWeapon, :to => Shuriken do
    condition do |request|
        request.target.nil? 

             ? false 

             : request.target.member.reflected_type == Samurai.to_clr_type
      end
  end
  ninject.bind IWeapon, :to => Sword
  ninject.bind IWarrior, :to => Samurai
end

Well that’s all. I hope you like it. I will be looking into more ways to integrate DLR stuff into Ninject the most obvious is allowing you to inject dynamic types into static classes.

Note: this entry was cross-posted from flanders.co.nz

Note: this entry was cross-posted.

If you follow my tweets or the IronRuby mailinglist then you would know that I’ve been working on taking IronRuby ASP.NET MVC from the prototype stages to a more complete application. For me this has been a great experience getting familiar with the insides of ASP.NET MVC as well as playing around with integrating IronRuby in an existing C# application.  

The guys over at MSFT (John Lam, Jimmy Schementi and Phil Haack) had previously created a prototype and I built upon their work. You can read more about the previous versions of the prototype.
http://www.iunknown.com/2008/06/ironruby-and-aspnet-mvc.html
http://blog.jimmy.schementi.com/2008/07/aspnet-and-dynamic-languages.html
http://haacked.com/archive/2008/06/12/ironruby-and-asp.net-bffs-forever.aspx
http://haacked.com/archive/2008/07/20/ironruby-aspnetmvc-prototype.aspx
http://haacked.com/archive/2009/02/17/aspnetmvc-ironruby-with-filters.aspx

In a previous post I explained what I had done I explained how I found an entry point and how to get started building your own mvc framework on top of asp.net MVC.

http://flanders.co.nz/2009/01/25/created-a-basic-integration-for-ironruby-and-aspnet-mvc/

How far am I now since my last post? Well we’ve got action filters, result filters, exception filters and authorization filters.  We have an IronRubyMvcApplication as a base HttpApplication. Which should get you pretty far when building apps with IronRuby MVC.

I’m currently looking at implementing selectors and aliased actions. When I’m done with that I guess I’ve got a fairly working implementation of asp.net MVC and I’ll start developing a sample with it.

I’ve actually started building the sample to find out if I’ve missed something. The sample will be using LightSpeed, IronRubyMVC as well as youtube and flickr.

I would love to hear from people that submit bugs or even patches. I’d also like to get some discussion going on what is going to happen to it in the future :)

You can find it at http://github.com/casualjim/ironruby-dbi or http://code.google.com/p/ironruby-dbi

I packaged the current version up in a zip

To install ironruby-dbi it should should suffice to extract the files you find in the ironruby-dbi archive to the libs folder of your ironruby installation.

For example I track the git repository for updates to ironruby and the git repository is cloned into C:\tools\ironruby

To install ironruby-dbi these are the steps you need to take:

• Extract the archive
• Copy the files to ruby/site_ruby/1.8

(on my machine the full path is: C:\tools\ironruby\merlin\external\languages\ruby\redist-libs\ruby\site_ruby\1.8)Start accessing databases :)

To do that start up an ironruby console

require 'dbi' 

conn = DBI.connect('DBI:ADONET:MSSQL:data source=(local);initial catalog=MyDatabase;user id=user;password=password')

statement = conn.execute "Select * from Users" 

while row=statement.fetch
  puts row
end

statement.finish

I spend most of my time on the mac and I wanted to be able to test ironruby stuff on it too. I tried to build IronRuby on my mac which doesn’t work straight away you have to patch it a little to make it work.

If you’re using the svn version then you can use the patch created by Seo Sanghyeon.
Michael Letterle has forked the ironruby git repository and created a branch called linux. You can find it on github.
For me the linux branch didn’t want to work and so I forked the ironruby repository too, created a branch called mono. My version is also up on github.

If you’re going to use the git layout of IronRuby, which is practically the same as what the IronRuby team uses at Microsoft. You’ll have to set an environment variable MERLIN_ROOT . I use a .bashrc file and added the following line to it:

export MERLIN_ROOT=’/Users/ivan/src/ironruby/merlin/main’

Now how do you get to those git branches?

Start a terminal session.

I have a directory src in which i download and compile sources. So I navigated into that directory src.

cd src

git clone git://github.com/casualjim/ironruby.git
cd ironruby
git checkout -b mono
git pull origin mono

Compiling IronRuby

cd merlin/main/Languages/Ruby
rake compile mono=1

Update:

You will also need a version of ruby installed, rake and the pathname2 gem

It won’t work with the latest release of mono. I’m using the trunk version of mono to build ironruby.
I’ve got instructions that could show you how to compile mono here.

Code

PDF of slides

You can find it here: http://manning.com/free/green_carrero.html

This paper tries to give you an introduction on what the ruby language is and how it could work for you. If you want to know more than what’s on those pages there is always the book: http://manning.com/carrero

You can read more about it on my blog: http://flanders.co.nz/2008/08/07/ironnails-introduction/

It’s still very early days for this project but if you like the concept and you have some free time please feel free to contribute. You can contact me through my blog or through github.

The github project can be found here: http://github.com/casualjim/ironnails

The DLR based languages don’t compile into static assemblies and this means that you can’t use those xml namespace definitons to reference your assemblies.  I wrote a fairly trivial control that acts like a hook for DLR based controls in the XAML tree.

You can check it out at codeplex.
http://codeplex.com/dynamicscriptcontrol

The idea behind this control is that you can "hook" your DLR based control into the visual tree by setting some properties.  You can set properties on the DLR based control by setting the Attributes property on the DynamicScriptControl

Let’s look at a quick example:

1. The ruby file defining a custom TextBox. But you can do whatever  you want in that ruby file of course.

All this textbox does is preset it’s text property to "I’m prefilled"

2. The xaml for the window

You first declare a namespace for the assembly that has the DynamicScriptControl. Next I have a StackPanel that contains 2 DynamicScriptControls. The first just contains the 2 mandatory properties. We need to know which class you want to instantiate in the file you provide by setting the ScriptFile property. This script file property is a path to your ruby file in my case prefilled_text_box.rb.
The second DynamicScriptControl is one where I want to initialize the control with my own text property. To declare those properties you have to add them to the Attributes collection of the DynamicScriptControl. At this moment it’s not smart enough to know which datatype you give it so you can specify a format string which was necessary in this case because text is a string.

3. The result

Michael Foord the author of IronPython In Action will provide the python integration in this control.

There was a release of the Dynamic Silverlight SDK earlier this week which contained the necessary source code files to compile a common DLR for both IronRuby and IronPython.  That is what makes it possible to support multiple scripting languages from the start. 

I’ve hosted the source code on google and you can find that at:

http://code.google.com/p/dynamic-script-control

You can find the book at http://manning.com/carrero
There is also a forum there where you can post suggestions and/or problems you may encounter when running the code samples. I look at it as my issue tracker :)

I’m currently working on a chapter where I build a complete twitter client with IronRuby and WPF (not silverlight as indicated on the current TOC). It is based on Witty but uses IronRuby instead of C# to drive the xaml. Also some storyboards have been replaced by IronRuby instead of by xaml stuff. It’s also not a straight port of Witty because I haven’t really looked at their code apart from the xaml that is.

Happy reading :)

Today we are going to use the files that get generated by the DSL script. We’re going to add some classes to silverlight.rb to enable a nicer api for generating elements from ruby. We left off last time with some code to generate 3 elements. That code wasn’t the prettiest code I’ve ever seen, apparently John Lam agrees and he has written a little DSL script for generating those elements. In today’s post we’ll be using that little script to generate the StackPanel etc.

Download the completed code

Just a refresher, here’s the code we ended up with the last time.

Let’s start replacing that code with something a little nicer. Open up the silverlight.rb file in your app folder and add the require directives at the top of your file. Next we’re going to need the Wpf::Builders module created by John Lam it’s included in the download. We’re going to need to add the following code in the silverlight.rb file:

That module takes care of dispatching the correct property names etc. Now that we have the module we can alter the SilverlightApplication a little bit. Let’s add a method add to that class that will be our entry point into the Wpf::Builders dsl.

Ok we still need to monkey patch a couple other classes before we’re ready to go. The first thing we see is that StackPanel has a setter method for Margin that takes an instance of Thickness. The property margin is defined on FrameworkElement, so that we can use it on every object that inherits of FrameworkElement. We’re also going to be addressing objects by their name. Not all of them have a name setter method so we’re going to ensure that all of them have one by monkey patching DependencyObject

This gives us the ability to set margins as if it were normal integer values.

The next thing we see is that there is an Orientation property that we’re going to set and that seems to take an enumeration of some sort. To accomplish this we’re going to monkey patch StackPanel.

We’re almost there don’t worry :). The next thing we see is that we need to be able to add child elements to that element. A StackPanel, DockPanel and so forth are all children of Panel so let’s patch Panel and enable this for more containers. To do this we need to include the module Wpf::Builders in the Panel class and we need to make sure we have all the necessary methods in there that will allow us to add children to that Panel.

We’ve now got us a little DSL for generating the necessary elements for this demo. All that is left to do now is write the initialize method in app.rb so that we get the same result as the last demo. Below we’ve got the content of the app.rb file

I hope you can see that Silverlight and IronRuby can really work together to help you build some cool things easily. The next post will deal with some animation, hope to see you there ;)

del.icio.us Tags: IronRuby,Silverlight

Technorati Tags: IronRuby,Silverlight