Binsor
Binsor: Shove Those Imports To Another File
Because Binsor is strongly typed, you need to specify the imports for all the types you are using. It can get quite long, at times, because you are usually crossing the entire application, so basically every namespace you can think of is there. I don't like that, it should be clear what is going on, and the imports should go elsewhere where they don't distract me. So I did it. You can now write: import namespaces from defaultImports.boo
#real code here
Binsor: Cross file extensibility
A word of advice, if you are not using an IoC, you don't have the problem of defining components, you have the one before that, of dependency management. I am talking here what happens after you embrace IoC, what the next pain points are. Having the configuration in a single place, being able to define both the shape of the application and its configuration is really nice. It makes a lot of things very easy. Until you want to send allow the user to extend a single facet of the configuration, but not allow them (or not expose them) to...
Binsor 2.0
All credit should go to Craig Neuwirt, for some amazing feats of syntax. He has managed to extend Binsor to include practically all of Windsor's configuration schema. This is important because previously we had to resort to either manual / ugly stuff or go back to XML (see: manual & ugly). This is important because some of the more interesting things that you can do with Windsor are done using the facilities, and Craig has made sure that Binsor will support the main ones in a natural manner, including out of the box support for the standard configuration model. Let...
Analyzing a DSL implementation
You were just handed a strange DSL implementation, it does stuff, and it may be cool, but you have no idea how it works. Craig Neuwirt recently did a major overhaul of Windsor ( I am going to post soon with the details of how cool it is now ), but I am now faced with the question, how do you grok such a thing? I thought that it would be useful to put a list of what I am doing to understand how the internals now works. It goes without saying, but the nitpickers will ask, that a...
Multi file DSLs
While a DSL can really cut down the amount of code that you need to write, putting everything in one file is not a good idea. But I like my DSLs to be script like, without the need for an explicit compilation step. I have thought about it for a while now, and yesterday ago Craig Neuwirt* asked how it can be done using Binsor. My default language is Boo, obviously, which is a static, compiled language that pretends that it is dynamic and scriptish, giving the best of all worlds. One of the cool things about Boo is...
Zero Friction Configurations
Today I broke down and added this to my windsor.boo config: serviceAssemblies = ( Assembly.Load("MyApp"), )
for asm in serviceAssemblies:
for type in asm.GetTypes():
continue unless type.NameSpace == "MyApp.Services"
continue if type.IsInterface or type.IsAbstract or type.GetInterfaces().Length == 0
Component(type.FullName, type.GetInterfaces()[0], type)
I was staring at the task of adding two lines to a config file that is less than a 100 lines (including imports & spacing), but that would have been an extra step that I needed to take, and I had intended to create three or five services in the next...
Convention over configuration: Structured approach
Hammett has a post that made me think. He is talking about configuring Spring for Java and has this to comment: I can’t understand this uncontrolled passion that java programmers carry for xml. I can certainly agree with him about that, but I got to the same point a long time ago with Windsor. I had an application which was rife with components. I am talking about many dozens of generic (as in MyComponent<T>) components, all of which required registration in the config file, which got to be fairly annoying very fast. I solved that by creating Binsor, a...
The Forum Sample Application
So, it looks like the vote goes decidefully for MonoRail, so that is what I am going to build it with. I have setup a project here: https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/SampleApplications/Hibernating.Forums I have decided to take advantage of this series and show some other cool stuff that I have used, from the Repository<T> & NHQG to Binsor and MonoRail Windsor Integration. The application is basically just UI and configuration right now. I did some very rough strcuturing of the UI in a way that should...
On debuggable configurations
Tomer Gabel commented on my post about debuggable configuration:This may be debuggable, but it sure as hell doesn't look like configuration to me. Configuration should be declarative and should not contain complex logic (what you show above definitely falls under that category in my book). This sort of script is, as far as I'm concerned, tantamount to collating all your configurable properties into one external, dynamically-compiled class -- in other words, hardcoded. Let me just point out what I tried to do when I started using this approach: ...
Rewriting COM+ in 10 lines of code
Okay, this is a lie, but it is nearly true. Take a look at this Binsor script: def OnNewTransaction(transaction as ITransaction, transactionMode as TransactionMode, isolationMode as IsolationMode): transaction.Enlist( TransactionScopeResourceAdapter(transactionMode) ) ...
Debuggable Configuration
Now try to do that with an XML Configuration File.