Now to dive into the subject of this article, one of the new features in Rails 3 that I really like is the use of UJS (Unobtrusive JavaScript) taking away all the inline Javascript that was generated by Rails inline within your HTML. UJS has many advantages over inline Javascript, the main advantages in my opinion being that Javascript is now no longer treated as a second class citizen, more easily managed (because it isn’t all over the place anymore) and that it makes it easier to build pages that work with and without Javascript.

For those of us that have been using the existing AJAX functionality in Rails 1 and Rails 2 it involves a bit of work. Helper methods such as link_to_remote and remote_form_for have been taken away, instead you now specify :remote => true as part of the options to the helpers that they were AJAX alternates for (such as link_to and form_for). Specifying the :remote => true option adds a custom attribute to the tag: data-remote=”true”. Javascript event observing is used to properly trigger the AJAX requests on click or submit (depending on which helper it’s being used on). If you take a look at the file public/javascripts/rails.js you’ll see how it works exactly (assuming that you understand Javascript and the Prototype framework).

The standard callbacks that used to exist as part of the remote functions are now gone too (you could pass in options such as :success, :failure, :before, :after, etc.), instead you will have to program them in Javascript. One of the upsides is that you can specify global behavior for all your AJAX requests by observing the “ajax:*” events (public/javascript/rails.js details which ones are fired). This can be incredibly useful per example when you want to show a spinner for your AJAX requests, you simply observe the “ajax:before” and “ajax:after” to show and hide the spinner in application.js (making this behavior available on all your pages instantly, very DRY!). You could even influence the behavior for each AJAX request with additional custom data attributes (per example the id of the spinner to show and hide).

The upgrade was relatively problem free, the only real issue that we ran into was that somewhere in between 2.1.2 and 2.3.4 the *_tag helpers (text_field_tag and such) have started behaving slightly different in relation to element ids. These helper methods now call the undocumented sanitize_to_id method, which cleans up the element ids by getting rid of characters such as [ and ] and putting in underscores instead. While this is a good change (the form_for helpers were already converting the field names to such element ids, so this change makes the helpers more consistent), it was unexpected (I have not seen any documentation referencing it, not in the 2.2 or 2.3 release notes). This changed a lot of ids in web forms that we were using, and it broke a fair bit of custom Javascript which we had to repair.

So, if you’re upgrading Rails from 2.1.2 or older to 2.3.4 ensure that you check your views for custom Javascript to ensure that any fields generated by the *_tag helper methods that are being referenced with Javascript are referenced properly.

Happy coding!

When you use the standard version of Ruby getting SQLite support is easy, you just install the sqlite3-ruby gem (gem install sqlite3-ruby) and you’re done (you need to have the SQLite libraries and dev headers installed on your system already of course). This does not work for JRuby because the sqlite3-ruby is a native gem (containing C code with extensions on standard Ruby).

So how do you get SQLite to work with JRuby and Rails? Get the gems for JRuby! Assuming that you have SQLite installed on your system, you simply need to install the activerecord-jdbcsqlite3-adapter gem (this will automatically try to install the activerecord-jdbc-adapter and jdbc-sqlite3 gems if you don’t already have them). In your Rails project edit config/database.yml and change the adapter type to jdbcsqlite3 and you’re done

There are a number of activerecord-jdbc gems available (just type “gem search –remote activerecord-jdbc” in your shell to see them), including connectors for Apache Derby, MySQL and PostgreSQL.

A term that’s uttered quite often by software developers everywhere is that they like to “scratch their own itch”, and I felt the same way when I started looking at software for my website again. While there are certainly good blogging tools and content management systems and frameworks out there, none of these seem to be exactly what I want (often they do a lot of things that I don’t want, and they lack a few things that I do want). While WordPress is certainly sufficient for the time being, I know I want to make something that scratches my itch

Most of the existing products that I have seen and tried are written in PHP (examples are: WordPress, Drupal, Joomla and more). Instead I’ll be using my preferred web application framework: Ruby on Rails. I’ll be using JRuby instead of regular Ruby, at least for development. I’ve heard good things about JRuby so far, using it for this project will give me a good chance to see how well it works.

As suggested by my colleague, I will be blogging here about my progress… so stay tuned