Abstract AST

In the first two articles I introduced Pysor, the Castle Windsor configuration tool using IronPython. Now I have added some exciting functions to exploit the nice hash table and list syntax feature in IronPython.

Since the second part of this series is possible to add (named) parameters to component registration. It accepted only both literal and referential scalars. In the current revision you can exploit the nice list syntax of Python using the square brackets to add arrays and list parameters.

A parameter is a string literal or a reference to an already registered service. This value is supplied either to a constructor parameter with the same name or a property.

A example used in the last part was to provide AdditionalMessage property like this:

add( "retriverWithParam", HtmlTitleRetriever, HtmlTitleRetriever,
	{'AdditionalMessage': "Test"})

Now suppose that we have a class that accepts an array of strings in the constructor.  We could provide them using the Python list syntax

add( "MessageStorage" , MessageStorage, MessageStorage,
	{'messages':['first message', 'second message' ]})

This syntax works not only for array but also for ILists.

Things get more interesting when you want to add an array of registered services. The method add returns a hook to the service. You can use this hook to reference the service in the parameters :

ftp = add( "ftp", FtpFileDownloader, FtpFileDownloader)

add( "MultipleDowloaderStorage", MultipleDowloaderStorage,
	MultipleDowloaderStorage, {'dowloaders' : [ ftp] })

Comparison

In this section I will compare the same configuration using traditional xml syntax and the Pysor syntax. I am sure not every body would prefer Pysor. I am pretty comfortable with xml, yet I don’t like it. I will choose Pysor anyway. In the next section I will make a small project and use both configuration mechanisms and let you find by yourself, which solution is more elegant and appropriate for you.

Not breaking the tradition of almost all IoC tutorials, we will need a logging service to be located dynamically. Additionally we have two implementations: ConsoleLog  and FileLog. FileLog expect a file name in its constructor..

public interface ILog
{
    void Log(string message);
}

public class FileLog : ILog
{
    private readonly string _fileName;
    public FileLog(string fileName)
    {
        _fileName = fileName;
    }

    public void Log(string message)
    {
        Console.WriteLine(_fileName+ " -> " + message);
    }
}

public class ConsoleLog : ILog
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

In additional we have an IAlgorithm interface with following members:

public interface IAlgorithm
{
    event EventHandler OnOperationDone;
    void Run();
}

Algorithm is a class implementing this interface. AlglorithmRunnner is a class that takes an algorithm with an array of loggers, starts the algorithm and notify all loggers when an event is fired.

Configuring this setup of dependencies in App.config would look much like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="castle" type=
"Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor"/>
  </configSections>

  <castle>
    <components>
      <component id="fileLog"
                 type="CastleComparison.FileLog, CastleComparison"
                 service="CastleComparison.ILog, CastleComparison">
        <parameters>
          <fileName>log.txt</fileName>
        </parameters>
      </component>

      <component id="consoleLog"
                 type="CastleComparison.ConsoleLog, CastleComparison"
                 service="CastleComparison.ILog, CastleComparison">
      </component>

      <component id="algorithm"
                 type="CastleComparison.Algorithm, CastleComparison"
                 service="CastleComparison.IAlgorithm, CastleComparison">
      </component>

      <component id="runner"
                 type="CastleComparison.AlgorithmRunner, CastleComparison">
        <parameters>
          <loggers>
            <array>
              <item>${consoleLog}</item>
              <item>${fileLog}</item>
            </array>
          </loggers>
        </parameters>
      </component>

    </components>
  </castle>
</configuration>

On the other hand, configuring it with Pysor is as simple as

clr.AddReference("CastleComparison")
from CastleComparison import *

fileLog = add("fileLog", ILog, FileLog,
	{"fileName":"log.txt"})
consoleLog = add("consoleLog", ILog, ConsoleLog)

add("algorithm ", IAlgorithm , Algorithm )

add("runner", AlgorithmRunner, AlgorithmRunner,
	{"loggers": [consoleLog, fileLog]})

Clearly, I will always choose the second configuration.

To-do’s

The updated to-do list is now

• Adding a nicer API for referencing assemblies and importing namespaces (I have now idea how to do it).
• Adding parameters to be passed to the constructor.
• Passing parameters as lists or arrays.
• Dictionary based parameters
• Referencing already registered implementation inside the same configuration script.
• Documenting and signing the assembly
• Lifestyle management
• Considering turning Pysor into an Interpreter to be used as the built-in XmlInterpreter

Source Code

Please don’t forget to download the code from GitHub and try it yourself.

All remarks , ideas, bug reports, etc. will be appreciated.

Castle Windsor is a very popular IoC container in the .Net world. Like almost all other containers it can be configured using either a fluent interface or an xml-based configuration file.

The fluent interface has the advantage of being strongly typed, what spares you a lot of errors caused by typos. On the other hand, it is hard coded and can’t be changed easily without recompiling (Actually you could use an IoC container to load you IoC container configuration dynamically but it give a rise to the question: “How do configure the container to load its own configuration?” )

The other option is to use an xml file. Despite being the most used solution in almost all containers it is really a very ugly solution. The configuration file can get very big and very complicated.

As I am reading IronPython in Action from Manning Publications, I thought I could configure Windsor using Python and a very tiny DSL. IronPython is an interpreted language for .Net framework. It combines the elegance of Python with the strength of .Net. Since it being interpreted it is a suitable solution for configuration.

For the beginning I will start with a simple solution, that can configure basic service without an enough for me to be able to configure just basic services without parameter zing. The syntax for configuring a simple implementation in Castle looks like:

container.AddComponent("service.name"
				typeof(IService>),
				typeof(Implementation));

Of course there is a whole bunch of other  settings like lifestyle and parameters, but I will ignore that for now.

Analyzing this one line I realized that all I need is a function with three arguments: the name of the coupling, the service type and the implementation type. SoI coded thus a function in C#:

private static void ConfigureContainer(IWindsorContainer container, string scriptPath)
{
	var engine = Python.CreateEngine();
    var runtime = engine.Runtime;
    var scope = runtime.CreateScope();
    scope.SetVariable("__main__", "__main__");
    Action<string, Type, Type> action =
			(name, service, impl)=>
				container.AddComponent(name, service, impl);

	//Inject this function into IronPython runtime
    scope.SetVariable("add",action);
    var script = engine.CreateScriptSourceFromFile(scriptPath);
    var code = script.Compile();
    code.Execute(scope);
}

To test this DSL I wrote a simple interface with a single implementation to bind them with Python.

namespace PythonConfig
{
    public interface IDependency
    {
        string Name
        { get; }
    }
    public class Dependency : IDependency
    {
        public string Name
        {
            get { return "Default"; }
        }
    }
}

And the Python configuration is just as simple as

import clr
clr.AddReference("PythonConfig")
from PythonConfig import *

add("name" , IDependency, Dependency)

Now everything is ready. You can configure the container using this file:

static void Main(string[] args)
{
    var container = new WindsorContainer();
    ConfigureContainer(container, "script.py");

    var depend= container.Resolve<IDependency>();
    Console.WriteLine(depend.Name);
    Console.ReadLine();
}

And … it works as expected!

Todo’s

I am very aware that this implementation is very limited and incomplete. It is just enough for my needs (That’s how DSL ought to be). Nevertheless, I will try to add some of the missing features. In particularly following  functionalities will be considered very soon:

• Adding a nicer API for referencing assemblies and importing namespaces.
• Adding parameters to be passed to the constructor.
• Referencing  already registered implementation inside the same configuration script.
• Lifestyle management

Links

• IronPython’s page on Codeplex.
• IronPython in Action an excellent (and currently the only the first) IronPython book by Michael Foord.
• Binsor: a Boo based DSL for Windsor by Ayende.