Empty Thoughts

There’s been some buzz lately about Hobo, a plugin extension to the Rails framework that makes it easy to do rapid prototyping of web applications. You can find out about all of the features at the HoboCentral website. One exciting feature is the implementation of DRYML, a way of drying up your views and providing extendable tag libraries.

Check out the screencasts. They’re very well done. I haven’t been this stunned by a screencast since I saw the original DHH Rails screencast. It’s exciting times.

The fine folks developing Slate, a content management system for Rails, have just released a Textile Editor plugin. This works well in conjunction with Err the Blog’s acts_as_textiled plugin.

About a week or two ago I emailed Benjamin Curtis, creator of the Agile Web Development plugin repository. I asked him if he would add the ability for users to be able to save a list of favorite plugins that they use all the time. I wanted a place to keep track of all the plugins I am interested in so I don’t have to keep going back and searching for them every time. I was pleasantly surprised when he emailed me back about a week later and said that he had implemented it. It works perfectly.

If you’re not familiar with Benjamin’s repository, I recommend that you head on over there as soon as you have a few spare hours. It’s easy to get lost in all the great plugins that are being developed. Thanks Benjamin and keep up the good work.

I’m a bit of a plugin hound. I really like the approach of Rails plugins because they force the implementor to offer up small ideas in a concise package. Also, plugins are easy to grok. Generally you can spend a small amount of time investigating what’s in the lib directory and get the essesense of the implementation. Often you can learn alot by looking at the plugin code. There’s some pretty impressive code out there. That said, not all plugins are created equal.

Some come without documentation. Many come without tests. You have to be aware of the code that you’re injecting into your Rails application. Does it play nicely with what else is going on in your app, or does it take more of a brute force approach? All of these things become important in the decision to use a plugin or not. Do you recognize and trust the author? What level of dependency will your application have on the plugin. In other words, if you need to upgrade Rails and the plugin is not longer supported, what impact will that have on your application?

Plugins are a great tool and there’s a tremendous number of plugins in the wild. But not all plugins are the same. Be smart about what you choose to use. Figure out a good list of criteria that works for you, and evaluate accordingly.

I recently started using Topfunky’s Power Tools Plugin to clean up some of my testing routines. It’s a nice little package that brings together lots of different asserts that have been out there in the wild in one form or another.

I really enjoy the assert_required_fields method. I used to implement my model checking like so:

def test_should_require_login
  assert_no_difference User, :count do
    u = create_user(:login => nil)
    assert u.errors.on(:login)
  end
end

...and now with the Topfunky Power Tools Plugin I end up with the following:

def test_should_require_login_password
  assert_required_fields :create_user, :login, :password
end

Notice how it allows you to check multiple fields at once. There’s a lot more available in the plugin, but sometimes all it takes is one or two little things to make your day.

Recently I’ve been spending a lot of time with Streamlined. The product is coming along quite well and recently a plugin version was released. One of the things that bugged me was lack of support for namespaced controllers. There’s a lot of controversary about namespaced controllers within the Rails community, but I’ve never had an issue with them and they help to provide good separation with larger projects. In the case of Streamlined, I’m using namespaced controllers for all of my administration pages. This results in a url like:

http://blog.railsconsulting.com/admin/categories

In addition to good separation namespaced controllers also insulate my own controllers from stepping on / or getting stepped on an acts_as_streamlined controller.

Anyway, enough justification. Correcting the namespaced issue is pretty simple. The problem is in the lib/streamlined_controller.rb file. The issues is how the streamlined code is arriving at the model name. Around line 404 in the file there is the following line:

@model_name ||= Inflector.singularize(self.class.name.chomp("Controller"))

What’s going on here is that in the original code it is taking the controller class name and getting rid of Controller from the end of it. In the case of a controller named UsersController this will result in a model name of User, which is correct. In the case of a namespaced controller named Admin::UserController the code results in a model named AdminUser, which obviously is not correct.

By changing it to read the following it will correct the problem:

@model_name ||= Inflector.classify(self.class.controller_name)

By referencing the internal method controller_name we will get back the correct controller name, sans the namespace, which in turn results in the correct model name.

If you’re receiving this error when using the streamlined plugin, I might have a solution for you:

“A copy of AuthenticatedSystem has been removed from the module tree but is still active!”

It’s taken me several hours of investigation but I found something that works. The issue is that in Rails 1.2 the order of initialization has changed. You can find a lot more information about this from Rick Olson’s blog.

The issue is that the PlugIns load before the application itself. Therefore the PlugIns cannot refer to the application or monkey patch it.

To correct this problem in streamlined we only need to comment out two lines; the require line to the application.rb file and the line that reminds us not to act_as_streamlined from the ApplicationController directly. The beginning of the module should look like the following:

#require "#{RAILS_ROOT}/app/controllers/application"
module StreamlinedController 
  def self.included(base) 
    #raise "Cannot extend ApplicationController with acts_as_streamlined: please extend individual controllers." if base.instance_of? ApplicationController 
    base.extend(ClassMethods) 
  end

The problem with these lines is that they are referring to the ApplicationController which creates a dependency between streamlined and the ApplicationController. As I understand it prevents its dependencies from being unloadable.

I’ve done some preliminary testing and it appears to be working fine. I will continue with some more thorough testing and report back if there are problems.