Dave Syer wrote a post on how you can use Grails’ DSL to configure the Spring Framework even without using Grails as your application framework. It is nice to see that Spring folks are writing about the benefits of LOP in configuration but I really think that Spring still needs a lot of changes to be on the right track.
The example relies on the Dynamic Language Support feature of Spring’s latest releases, specifically its capacity of letting scripting code to be inlined into your application context configuration file.
It would be really cool if Spring have it’s own (probably External) DSL to configure all the things needed to use it. It actually des have some sort of language (an Internal DSL embedded into XML) but since Spring 2 was launched I lost my interest in the project. Ok, it used to be a real pain to write Spring 1.x’s XML configuration files but at least it used an elegant language, with only a few primitives you cold do anything. That language was about Beans, nothing more.
Spring 2.x got such a complex configuration language that I never could find someone that understood all of its subtleties. Surely the main driver for that change was the fact that Spring is not about Dependency Injection. In the first versions we had to use those method name conventions, interfaces to implement and etc. Spring 2 resolved much of these by using new language constructs. The problem is that a language to support all of those constructs will often be bloated.
2.0 complicated things, but did you see the new options in 2.5? It is a frightening sight…
Spring is now far from the days where one could pick it up and learn to use in a week, there are now whole conferences revolving around Spring, companies making money solely with Spring consulting, large “child projects”, customized IDEs, etc. When a product gains such commercial momentum, it’s next to impossible to maintain the original simplicity. I’m not saying that “those evil capitalists” are adding features left and right to justify consultancy income; featuritis is just the normal course events when a product gets large enough.
Now, back to the technical suggestion, I think that IoC is something that must be addressed at the language level. Something like Smalltalk’s metaclasses or Beta’s virtual classes would go a long way towards solving the issue. Gilad Bracha is doing some work in this direction with a new dialect of Smalltalk, IIUC he is restricting the metaclass system to enforce some consistency propreties (currently, Smalltalk metaclasses require programmer discipline in order to avoid some problems). In Java there is this (http://tal.forum2.org/static/cv/Factories.pdf) proposal which seems to make sense, but like other proposed additions to Java, feels kind of kludgy.
Enough rambling…
You can use Grails’ BeanBuilder standalone without the XML if you want to avoid XML completely