Introducting Binsor: The Boo DSL For Windsor
On the on-going battle between yours truly and XML, there has been a score on the good side!
I just finished implementing most of the usable functionality in Binsor, which is a Boo DSL* that is directed at configuring Windsor. Before I get into the details, take a look at the most minimal xml configuration possible for Windsor:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<components>
<component id="default.repository"
service ="Rhino.Commons.IRepository`1, Rhino.Commons"
type="Rhino.Commons.NHRepository`1, Rhino.Commons"/>
</components>
</configuration>
Now, let us take a look at the same configuration using Binsor:
import Rhino.Commons
Component("defualt_repository", IRepository, NHRepository)
This is it!
What is even more fun, is that you get to treat the component as if it was a real object, instead of a lump of configuration data that you need to work with. Take a look at how you do it for Windsor using XML here.
Take a look at how you do it using Binsor:
import Rhino.Commons
email = Component("email_sender", ISender, EmailSender)
email.Host = "example.dot.org"
It can't get any more natural than that.
Of course, the problem with the XML configuration for Windsor only start when you crazy with it and build an object graph of arbitrary depth no less than five. I stopped trying to make it work when I got 15 different XML files, mostly containing the same information.
Now, if I want to add the same component to listen for each of my server, I can simple do this:
import Rhino.Commons
servers = [ "server1", "server2", "server3"]
for server in servers:
listerner = Component("listener_for_${server}", IListener, WSListener)
listener.Server = server
If I want to make a change to the configuration, I can make it in one place, and all the listeners are updated.
Did I mention already that it is debuggable ?!
* Maybe DSL is taking it a bit too much, though. It is a single class that has some fancy sticks in it, and a lot of Boo magic.
Comments
Comment preview