Rails Plugins: Will somebody PLEASE think of the children?

Posted by trevor Wed, 26 Oct 2005 16:33:00 GMT

First of all, if plugins are new to you then you should definitely look at Jamis Buck’s guide to plugins before going any further.

Okay, so by now you know everything about plugins right?

So, I had one of those ‘uh-oh’ moments last night.

The Issue

I was worried that putting my acts_as_enumerated into ActiveRecord::Acts::Enumerated was a bad idea. I emailed Jamis and asked if plugin authors should avoid any rails module namespaces and he said:

That’s a really interesting question. I think I would answer “Yes”, but I’m not sure why. :)

It feels more natural to me if people follow a naming convention similar to how things are done in Javaland, where modules are namespaced by their vendor. So:

TrevorSquires::Acts::Enumerated

or something :)

He went on to point out that right now there are no guidelines or best practices.

Considering the number of plugins that have already been written it’s probably a good idea to start thinking about this now.

The Opinion

So here’s my opinion, presented in a way that I hope everyone from newbies (like me), to seasoned pros can understand. I’d appreciate feedback from others on this.

A plugin author has two namespaces to be concerned about:

  • $LOAD_PATH
  • Modules

The two namespaces kind-of overlap, but they don’t have to. I have a file called /lib/active_record/virtual_enumerations.rb that defines a ActiveRecord::VirtualEnumerations module and re-opens the ruby Module class. The name of the file doesn’t have to dictate its contents.

But the name of the file plays a role in being able to load your code in the first place – via the require keyword. If there are two plugins that have a /lib/chunky_bacon.rb file then require 'chunky_bacon' will load the first one found in $LOAD_PATH.

Now, as long as your init.rb does a require of all necessary files during initialization this won’t be an issue because during init your plugin’s /lib directory is the first one in $LOAD_PATH.

However, it may become an issue if you, or any other package that happens to require 'chunky_bacon', decide to defer require calls until a later time.

Even though for most people the $LOAD_PATH won’t be an issue, I believe plugin authors should be encouraged to use a directory structure, unique to themselves, within their /lib directory. Using someone else’s plugin for an example:


/lib/techno_weenie/acts_as_paranoid.rb

Not only does it solve potential $LOAD_PATH problems but it also serves as a reminder that you really ought to make your Module namespaces unique as well (as Jamis said above).

Comments?

Posted in code

Announcement: New Rails Plugin

Posted by trevor Tue, 25 Oct 2005 20:33:00 GMT

I’m pleased to announce the release of a new rails plugin for ActiveRecord, chock full o’goodness from:

  • acts_as_enumerated
  • has_enumerated
  • ActiveRecord::VirtualEnumerations

What is it?

As part of the work I’ve been doing at Site5.com (who have very graciously allowed me to release this code into the wild) I put together an extension to treat an ActiveRecord model as an enumeration. I.e.:


class BookingStatus < ActiveRecord::Base
  acts_as_enumerated, :order => 'position ASC'
end

booking.status = BookingStatus[:confirmed]

Values for acts_as_enumerated models are cached (reducing hits to the database) and you can define ‘virtual’ acts_as_enumeration classes, eliminating the need to clutter your models directory with classes that do nothing more than acts_as_enumerated.

The has_enumerated macro allows your models to refer to acts_as_enumerated instances without resorting to using belongs_to (which can require you to jump through hoops to avoid the database hit when retrieving the enumeration value).

I should point out that this isn’t the first time something like this has been done. Michael Shuerig sent a mail to the rails list a while back (when I was first looking at this feature) outlining how he was adding enumerations to his Boilerplate library.

Boilerplate’s enumerations differ from this plugin in some pretty significant ways but Michael’s technique of hooking into Module.const_missing was the missing piece of the puzzle I needed to eliminate clutter in the models directory – I’m very grateful for that.

How is it installed?

Well, the new rails ‘plugins’ feature makes packaging and releasing extensions a lot more straight forward.

First of all, you need to be running a plugin-compatible version of rails (0.14 and above). Then you simply:


cd vendor/plugins
svn export http://svn.protocool.com/rails/plugins/enumerations_mixin/trunk \
   enumerations_mixin

The README_ENUMERATIONS file should be enough to get you started – when I manage to scrape together some spare time I’ll insert some (hopefully) more helpful rdoc.

What’s missing?

Well, proper documentation, for a start. Apart from that it’s fully functional.

Enjoy!

Update

Years later and this plugin is now hosted on github

Posted in code

Site5 Teaser

Posted by trevor Tue, 25 Oct 2005 20:29:39 GMT

The day is nearly upon us. A little teaser perhaps?