Posts Tagged ‘DSL’

Using IronPython to configure Castle Windsor III

Pysor Series

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.

Using IronPython to configure Castle Windsor II

Pysor Series

In the last article I introduced a small Castle Windsor configuration tool using IronPython. This tool enabled us to add service implementation in an easer to read way. On the other hand advanced usages like optional and constructer parameters were not possible.

In this article I will continue developing Pysor (As I called it!) to accept parameters. Before introducing the new functionality I will  show what are parameters and when and how would you want to use them. For the sake of demonstration I will borrow the demo application from the very good article series from Simone Busoli about Castle Windsor. If you didn’t read it then go read it all and come back.

The developed application is an html title retriever. It downloads an html string and then extract the title tag from it.  For downloading the the html document it uses an I Downloader service  that accepts an Uri object and downloads it if it can handle the scheme. For Example we have an HtmlDownloader, FileDownloader, etc. The other needed service is ITitleScraper which extract the <title> tag contents.

public interface IFileDownloader
{
    string Download(Uri file);
    bool SupportsUriScheme(Uri file);
}

public interface ITitleScraper
{
    string Scrape(string fileContents);
}

For the purpose of accelerating the unit tests I changed the downloader to not really download the files but return a fake text instead.

Having the constructor :

public HtmlTitleRetriever(IFileDownloader downloader, ITitleScraper scraper)
{
    AdditionalMessage = "";
    Downloader = downloader;
    Scraper = scraper;
}

with AdditionalMessage as a property indicates a short message, that will be concatenated with retrieved tile, we can now configure the container:

add( "parsingScraper" , ITitleScraper, StringParsingTitleScraper)

add( "HttpFileDownloader", IFileDownloader, HttpFileDownloader)

add( "retriver", HtmlTitleRetriever, HtmlTitleRetriever)

And everything works like expected. Now suppose we want to set the AdditionalMessage for each initiated object. Using xml configuration this could be achieved using a parameters tag  containing all parameters in a dictionary-like fashion.

The most appropriate data structure for this purpose in Python would be a hash which is equivalent to a Dictionary in the .Net  world.

Because C# in the current version doesn’t support optional or named parameters and because I don’t  know whether Python supports method overloading I added a Python method with supply the C# method with default value for missing arguments.

def add(name, service, impl, params={}):
	addComponent(name, service, impl, params)

Using this new method you can now set the AdditionalMessage value for each object:

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

We test it with

[Test]
public void CanProvideOptionalParameters()
{
    var obj = container.Resolve<HtmlTitleRetriever>("retriverWithParam");
    Assert.AreNotEqual("", obj.AdditionalMessage);
}

And of course it works.

Notice that in line 4 we specified the name of the configuration node to use because have added the service HtmlTitleRetriever twice.

The other use of parameters is to specify an implementation for some service to be used.  If you have for example another IDownloader implementation, that retrieves files sing the ftp protocol and we want to use this implementation for the constructor.  In xml we could do it using ${name} to reference the name of an already registered service. In Pysor we can use this notation as well. But to make it more like a usual program I modified the add function to return a string to be used whenever you need to reference this implementation.

Func<string, Type, Type, IDictionary<object, object> , string> action =
     (name, service, impl, parameters) =>
         {
             var pairs = parameters.ToList();
             var reg = Component
                 .For(service)
                 .ImplementedBy(impl)
                 .Named(name);

             if (pairs.Count > 0)
             {
                 var param = (from pair in pairs
                              select Parameter
                                 .ForKey(pair.Key.ToString())
                                 .Eq(pair.Value.ToString())
                             ).ToArray();
                 reg = reg.Parameters(param);
             }

             container.Register(reg);
             return "${" + name + "}";
         };

 //Inject this function into IronPython runtime
scope.SetVariable("addComponent", action);

And the Python wrapper function looks now like:

def add(name, service, impl, params={}):
	return addComponent(name, service, impl, params)

We are now ready to register a retriever that uses a concrete implementation:

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

add( "ftpRetriver", HtmlTitleRetriever, HtmlTitleRetriever,
	{'downloader': ftp})
[Test]
public void CanProvideSpecificImplimentationParameters()
{
    var obj = container.Resolve<HtmlTitleRetriever>("ftpRetriver");
    Assert.IsInstanceOf<FtpFileDownloader>(obj.Downloader);
}

We are finished for now.

 

To-do’s

The updated to-do list is now

  • 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

Source Code

The source code of Pysor is available to download from GitHub

https://github.com/mouk/Pysor/

Using IronPython to configure Castle Windsor I

Pysor Series

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