Posts Tagged ‘Rails’

Rails 3: lib directory files now need to be manually required

Tuesday, July 27th, 2010

Today Rails 3 Release Candidate was released. I upgraded the application I’m currently building and to my great displeasure discovered:

active_support/inflector/methods.rb:124:in
`block in constantize':
uninitialized constant [class] (NameError)

Turns out the custom library files you write and store in the ‘lib’ directory of your app are no longer automatically included on application boot. Luckily the fix is simple. In your Application.rb configuration file add the following line to automatically load all ruby files in the ‘lib’ directory:

Dir.glob("./lib/*.{rb}").each { |file| require file }

Hopefully this can save someone time and frustration.

—————–
now playing : Jes – Ghost

Rails 3 howto: restricting named routes to specific http methods

Thursday, June 10th, 2010

Migrating my project’s codebase to Rails 3 beta from Rails 2.3.x was fairly painless except for the changes to the router.

Most files only needed a few changes, but my highly customized routes.rb file was a four hour ordeal that I hope this post can help save someone else time as Rails 3 documentation for declaring methods for named routes is sparse at best right now.

The premise of what my app needs to have happen is the RESTful routes that are automatically created by scaffolding need to be modified to live at my domain’s root without relying on any web server tricks. For the rest of this post let’s focus on just one of these overrides: the “new” verb for the “events” controller.

Default route created via scaffolding is:

http://domain.com/events/new

However, I want the new_event helper to point to:

http://domain.com/new

In Rails 2.3.x this is accomplished via declaring a named route with a conditions statement restricting to only ‘GET’ requests:

map.new_event 'new.:format',

:controller=>"events",

:action=>"new",

:conditions => {:method => :get}

In Rails 3, the new way to do named routes looks like:

match 'new(.:format)' => 'events#new',

:as => 'new_event'

Seems simple, but when the conditions statement restricting to only the ‘GET’ method is added it’s ignored.
The following does NOT work:

match 'new(.:format)' => 'events#new',

:as => 'new_event',

:conditions => {:method => :get}

In Rails 3 the ‘method’ condition is ignored by design because the proper way to limit the named route override to a specific http method is:

get 'new(.:format)' => 'events#new',

:as => 'new_event'

The beginning keyword can be any one of the http methods: get, post, put, or delete

Pretty sexy to say the least!, just wish it was better documented. Hope this helps others out.?

—————–
now playing: Hans Zimmer & James Newton Howard – Molossus

Howto fix mysql gem not working with Rails 3 (OS X Snow Leopard)

Monday, June 7th, 2010

I ran into a problem where the MySQL gem would install properly but when I went to migrate my database it would fail with the following error:

Please install the mysql gem and try again: gem install mysql. rake aborted! no such file to load — mysql

It turns out that database gem requirements should be declared in the project’s Gemfile. Add the following line to the Gemfile:

gem ‘mysql’, :require => ‘mysql’

Then in the top directory of your rails application run:

bundle install

You should now be able to migrate your MySQL databases.

The technical change in Rails 3 that requires this extra step is that the bundler reads the gemfile and then creates links in either the [application directory]/.bundle directory to the system gems, or alternativly downloads and installs them into the [application directory]/.bundle directory.

The concept is to allow gems to be installed per project that do not need to be installed system-wide in the system gem repository. This helps to reduce version collisions and duplications. Both of which are highly important now that rails 3 allows multiple rails applications to live together.

—————–
now playing: TiĆ«sto Feat. Maxi Jazz – Dance4Llife