I was wondering if we could list the plugins for RoR in this forum, that are useful? In particular, I was wondering about the plugin that lets you do revision history.

Here are my usual suspects:

• exception_notification – Mandatory for production. sends you an email every time an exception is raised.
• rspec, rspec_on_rails – Easier, more readable testing than the default Test::Unit, in my opinion.
• haml – Cleaner HTML/CSS, both in your views, and in “view source” in your browser.
• annotate models – Adds a rake task that puts a description of the database table in a comment block at the top of each of your models.
• redhillonrails_core – Provides support for foreign key enforcement in your migrations, among a couple other features. Useful for database nerds like me.
• assert_request – Allows you to declare and enforce the method/params interface to all of your actions. This can make your application more secure, reduces validation code in your actions, and can prevent some obscure bugs when your views call your actions with incomplete/unexpected information.
• atom_feed_helper – Makes it easy to create feeds for your indexes. Might be built into rails 2.0 now?

Those are in rough order of importance to me, with the top four being almost universal in my projects. The rest of them depend more on the app’s features and how robust it needs to be.

Sorry there are no links, but I procrastinated long enough on this reply! A quick google search should turn each of them up.

Maybe after the next meeting ActiveScaffold will be in there too…

Regarding acts_as_versioned, the plugin for revision history, I’ve pulled it apart from top to bottom before and used it a good bit.

It’s fairly simplistic, and has its limitations. As such, I’d suggest reading it all and understanding it pretty thoroughly to make sure it does what you want and to make sure you understand the limitations. Also, there’s not any documentation for it, so you pretty much have to read the code to get full value out of it!

Here’s a brief explanation of how it works: Let’s say you have a table called “customers” that you want to version. You declare it to be “acts_as_versioned” in the model, and create a nearly-identical table called “customers_versions” in the database. The “customers” table will hold the current version of the data (as usual), and the “customers_versions” table now holds all of the old copies of the “customers” records.

Now each time you save a customer, the plugin will save a copy of the old record in the “customers_versions” table and increment the version number on the current table. Since the “customers” table is virtually identical to the one that you’d have if you weren’t using acts_as_versioned (it just has an extra column to tell you the current version for each record), ActiveRecord and anything else can use that current version and ignore the fact that this is a “versioned” table.

If you want to go get a previous version of the customer, the plugin simply looks in the “customers_versions” table for the same record that has the previous version number. It then generates a new instance of the model with that data and hands it back to you. If you save it, you’ll save a new version and essentially revert back to the old data that you requested.

That’s basically it. There are a couple other nice methods to help you traverse the history for a record and do some simple manipulations. It’s a pretty simple plugin, as versioning goes.

So what are the limitations? The plugin just saves a copy of all the record’s attributes into its history, without any regard for what those attributes mean. This works fine if you’re dealing with attributes that don’t have any special meaning to rails, like “first_name”, “title”, or “body”. However, it doesn’t work well at all for things like “contact_id”, or “position”. The reason is that those attributes refer to other records; records that might have changed since the last version was saved. If the old record is resurrected, and contact_id is no longer valid, or if the position of the neighboring records has changed (“position” is used by acts_as_list), then your referential integrity is going to be broken. You’ll call “customer.contact”, and you’ll get an exception since the old contact_id can no longer be found in the current database.

Versioning relational data is really hard. I’ve read big fat books on it (I can dig up the title if you really want it), and I have to say that it’s not worth implementing yourself unless it’s the point of the entire exercise—it shouldn’t just be a feature in your application.

So basically, if you’re using it to version unrelated data like wiki pages, you’re fine. You’ll get in trouble if you want to use it to version positional data (e.g. individual items in an ordered list) or relational data (e.g. a family tree).

Going along with the versioning stuff, we’ve used acts_as_paranoid a good bit before, and while it has a couple obscure limitations, it works fine. Basically, this is a plugin that provides “undelete” support. It simply marks your records as deleted rather than actually deleting them from the table, and then overrides the “find” method to return only undeleted items by default.

This plugin is also an excellent read. I highly recommend reading and understanding both acts_as_paranoid and acts_as_versioned, whether you’re going to use them or not. They’re great structural templates for creating your own plugins and the code, while sparse on comments and documentation, is very well written. You’ll learn a lot about changing ActiveRecord’s default behavior and about metaprogramming.

Both plugins would be much easier to understand if they weren’t so configurable—the column names that they use are flexible, which makes the code less readable.

For the record, I believe that both plugins are written by Rick Olsen, who’s now the core member that’s responsible for much of ActiveRecord itself.

Here’s another interesting plugin for creating custom find queries on your ActiveRecord models. This seems very concise, and would probably make for much more readable code in the end, even if your queries aren’t complex. I’m a big fan of creating custom methods for find queries, since something like

Post.find_recent

is more clear than

Post.find(:all, :order => "created_at DESC", :limit => 10)

I further like his convention of dropping the leading “find_” from the method name, so that “Post.find_recent” just becomes “Post.recent”.

http://www.pivotalblabs.com/articles/2007/09/02…

One more!

I know that someone mentioned jQuery as a good javascript library; an alternative to Prototype and Scriptaculous. I will definitely be checking jQuery out, since its syntax seems a little easier and more sensible.

One of the big downsides though is that Prototype and Scriptaculous are already tightly integrated into Rails with all sorts of helpful helpers. It turns out there’s a jq4r plugin that is starting to produce the same helpers for jQuery. Here’s the blog:

http://jq4r.blogspot.com/

Just read about the make_resourceful plugin; seems like it would be really useful for RESTful development. One gotcha is that it requires haml.

Regarding jq4r,there’s another one called jRails