Full details can be found in the commit on the github mirror.

As I’m not alone in having this problem, here’s a quick fix.

At the bottom of environment.rb;

require 'tagging_extensions'
require 'tag'

John Nunemaker recently released his User Stamp plug-in which stamps records with the ID of the users that created and last updated. The implementation is quite clever, as he’s managed to work around the usual hack of storing the current user ID in Thread.current to make it accessible to the model by using a Sweeper, as they have access to controllers (and hence the current_user method).

I’ve taken his code a bit further by creating a Log model which stores a polymorphic reference to the record affected, the event that occurred (e.g. ‘deleted’ or ‘updated’), the current user ID and the time it happened.

The Log model;

class Log < ActiveRecord::Base
 
  # Relationships
  belongs_to :user
  belongs_to :loggable, :polymorphic => :true
 
  # Validations
  validates_presence_of :loggable_type
  validates_presence_of :loggable_id
  validates_presence_of :action
  validates_presence_of :user
 
end

The migration;

class CreateLogs < ActiveRecord::Migration
  def self.up
    create_table :logs do |t|
      t.string :loggable_type
      t.integer :loggable_id
      t.string :action
      t.references :user
      t.timestamps
    end
    add_index :logs, :loggable_id
    add_index :logs, :user_id
  end
 
  def self.down
    drop_table :logs
  end
end

Additional callback methods added to UserStampSweeper;

  def after_create(record)
    add_log(record, 'created')    
  end
 
  def after_update(record)
    add_log(record, 'updated')    
  end
 
  def after_destroy(record)
    add_log(record, 'delete')    
  end
 
  private
  def add_log(record, action)
    Log.create(
      :loggable_type => record.class.to_s, 
      :loggable_id => record.id, 
      :action => action, 
      :user => current_user
    )
  end

Displaying the logs;

<% for log in @logs %>
  <tr>
    <td><%= link_to (h log.loggable.log_name), [:admin, log.loggable] %></td>
    <td><%= h log.loggable_type %></td>
    <td><%= h log.action %></td>
     <td><%= link_to (h log.user.display_name), [:admin, log.user] %></td>
    <td><%= log.created_at.to_s %></td>
  </tr>
<% end %>

The sample Rails application has also been updated to take into account the slightly changed syntax for specifying your list id(s);

Mailbuild.list_id = 'LIST_ID_HERE'

…is now…

Mailbuild.list_ids = {:newsletter = 'LIST_ID_HERE'}

All API calls take a list id as their last parameter, which defaults to the first id you declare in the list_ids hash.

You can use a specific subscriber list id as follows;

Mailbuild.add(params[:email], params[:name], Mailbuild.list_ids[:newsletter])

The documentation explains what parameters each method accepts.

To make it easier to get this data into your Rails application, I’ve created two generators which automatically create the models, migrations and data you’ll need and bundled them up in a handy Rails plug-in.

Usage couldn’t be simpler…

script/plugin install git://github.com/cameronyule/isodata.git

If you want country data…

script/generate countries
rake db:migrate
rake isodata:db:countries

…and for languages…

script/generate languages
rake db:migrate
rake isodata:db:languages

Check out the isodata project on Github.

To try and make things easier, I’ve made a sample – albeit basic – Rails application to show other people how I managed it.

I’ve created a project on Github to host it, feel free to check it out and let me know how you get on. The only instructions you should need are in the README file, but feel free to leave comments here if you do need a hand.

To make it easier to figure out how to use it, I’ve also created a fully functional Rails application which demonstrates all the API calls available.

To use it all you have to do is grab a copy from subversion…

svn co http://mailbuild.rubyforge.org/svn/rails_mailbuild_example/

… make sure you have the mailbuild gem installed …

cd rails_mailbuild_example
# OS X/Linux users may have to prefix this with sudo
rake gems:install

… and edit config/initializers/mailbuild.rb, adding your own API key, List ID and sub-domain.

# You can get this information from your Mailbuild admin
Mailbuild.api_key = ''
Mailbuild.list_id = ''
Mailbuild.subdomain = ''

Hopefully that’s all there is to it, but if you run into any problems feel free to add a support request or bug report on Rubyforge.

Update 2

I’m now using a simpler method which appears to be working – albeit with one caveat, which is due to a conflict between the Asset Packager plug-in and the Engines AssetHelpers extensions (I’ve simply disabled those extensions).

In config/environments/development.rb:

config.after_initialize {
  Dependencies.load_once_paths = []
}

Tip found on this ticket on the old Rails Trac.

Since moving to Rails/Engines 2.1, I’ve been irritated with having to restart Mongrel each time I make a change to a controller or model in my engine. This wasn’t an issue in Engines 1.2 as it had a load of custom initialisation code, but with 2.x moving closer to the way Rails itself works – see this post on the rails plugin initialization process by Rick Olson for more details – it’s become a problem.

Unfortunately the solution Rick proposed in his post wasn’t working for me, but a thread on the Engines development mailing list has provided a solution – add the following to the init.rb file of your engine and you’ll no longer have to restart your web server to see changes in your files.

I’ve wrapped the code in a check to see if we’re running in the development environment, as in the majority of cases you’ll want things to work as normal in production.

if Rails.env == 'development'
  Rails::Plugin.class_eval do
     def reloadable!
       load_paths.each { |p| Dependencies.load_once_paths.delete(p) }
     end
  end
 
  reloadable!
end

I’ve been using Globalite in the Rails project I’m working on and while it’s the best solution I’ve tried, I was always frustrated by the use of YAML for it’s locale files. Thankfully the changes in Rails 2.2 will likely mean a move to pure Ruby locale files, introducing the benefits of namespaces and the ability to override/extend generic files with site-specific ones.

Now we just have to wait a few months for the release and see what plugins adapt/appear to take advantage of it.