Some dads live for moments like when their son can beat them at basketball or throw a touchdown pass at a high school football game. Since my family seems to share my, ahem, lack of athletic prowess, I mostly get my "dad pride" fixes in different ways. For example, today my 10 yr old son asked me a question that nearly brought a tear to his old man's eye:
"Dad is there a job you can have when you grow up where you use Gimp?"
:)
Wednesday, August 8, 2007
Thursday, August 2, 2007
Spring Rails Plugin 0.1
Well, I finally checked in my code for a Spring Rails plugin. Consider it pre-alpha at this point. It's unit tested, and I made a simple example app to prove that it works. But that's about it. So if you find it useful, try it out and let me know so I can decide where to go with it next.
To install the plugin:
You'll need to get a basic Rails application working with the goldspike plugin in order for the Spring plugin to be of use. Currently it loads the Spring ApplicationContext by getting it from the ServletContext (which assumes you are using the Spring context listener to put it there). So if you're not running Rails in a servlet engine it doesn't work. If there is real interest in having the plugin be able to get an app context from somewhere else I'll look at supporting that down the road.
For an example of how to use it in a controller, see my previous post.
Why you shouldn't use it
If you're a Java programmer new to (J)Ruby and are thinking: "Awesome, I'll use Spring in all my Rails apps because Spring is awesome!" you need to hold up a second. Spring is awesome -- when you are developing Java applications. But in Ruby, dependency injection turns out to be unnecessary a whole lot of the time. This is because the Ruby language allows you to change things in a more straightforward way. And even if there were cases where you needed DI in Ruby there are probably better choices. I see the Spring plugin being useful where you have existing J2EE code wired together with Spring and want to front end it in JRuby on Rails. So use this plugin if you need it, but if you don't, then don't.
Don't take my word for DI and Ruby, my friend Jim had this blog post about it after our IM conversation. See the comments where other Ruby heavyweights weigh in on the subject.
To install the plugin:
script/plugin install svn://rubyforge.org/var/svn/jruby-extras/trunk/rails-integration/plugins/spring
You'll need to get a basic Rails application working with the goldspike plugin in order for the Spring plugin to be of use. Currently it loads the Spring ApplicationContext by getting it from the ServletContext (which assumes you are using the Spring context listener to put it there). So if you're not running Rails in a servlet engine it doesn't work. If there is real interest in having the plugin be able to get an app context from somewhere else I'll look at supporting that down the road.
For an example of how to use it in a controller, see my previous post.
Why you shouldn't use it
If you're a Java programmer new to (J)Ruby and are thinking: "Awesome, I'll use Spring in all my Rails apps because Spring is awesome!" you need to hold up a second. Spring is awesome -- when you are developing Java applications. But in Ruby, dependency injection turns out to be unnecessary a whole lot of the time. This is because the Ruby language allows you to change things in a more straightforward way. And even if there were cases where you needed DI in Ruby there are probably better choices. I see the Spring plugin being useful where you have existing J2EE code wired together with Spring and want to front end it in JRuby on Rails. So use this plugin if you need it, but if you don't, then don't.
Don't take my word for DI and Ruby, my friend Jim had this blog post about it after our IM conversation. See the comments where other Ruby heavyweights weigh in on the subject.
Subscribe to:
Posts (Atom)