Posts Tagged ‘rails’

Mailbuild gem 1.1

Wednesday, September 3rd, 2008

I’ve pushed a small update to the Mailbuild gem this morning which adds support for multiple subscriber lists, enabling you to manage different types of subscribers from within your application.

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.

ISOdata Rails plugin

Tuesday, August 5th, 2008

For anyone working on a Rails application which deals with countries or languages, the official source of data is the International Standards Association, specifically ISO 3166 for countries and ISO 639 for languages.

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.

Rails 2.1 SWFUpload Example

Thursday, July 31st, 2008

There’s been a few posts lately on getting SWFUpload working with Rails 2.1, attachment_fu and the restful-authentication plugins.

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.

A Ruby/Rails interface to Mailbuild API

Thursday, July 24th, 2008

I’m pleased to announce the release of the first version of my Mailbuild API interface, which I’m distributing as a Rubygem.

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.

Make Rails Engines 2 reload in development mode

Wednesday, July 23rd, 2008

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.


UPDATE: I’ve since stopped using this method. While it did allow for everything short of library files to be reloaded between requests, making the development process far less painful, I ran into a problem with ActiveRecord where deeply-nested (3 associations) models were behaving strangely on reload (they’d work fine first time, but not afterwards).


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

Internationalisation in edge Rails

Wednesday, July 23rd, 2008

After the announcement yesterday that Rails 2.2 will have support for internationalisation (i18n) in the core, I read the linked articles and was slightly surprised that rather than unifying/replacing the i18n plugins currently available, it will actually provide an API which makes creating a back-end for handling your locales easier.

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.