In a previous post I showed how to get around a bug in Prototype that was ignoring the "on" parameter of the observe_field function. The solution I originally posted no longer works with the latest version of Rails and Prototype. Although the documentation for observe_field received a facelift, somehow the Rails team still missed the fact that the :on function doesn't work with the current version of Prototype. Or maybe its the Prototype guys we should be after here. :-)

The new fix requires a change to both prototype.js and a small Rails core update.

I will start with the update to prototype.js. Search for Abstract.EventObserver (around line 3632 in my version). That should now read

Abstract.EventObserver = Class.create({
  initialize: function(element, callback, trigger) {
    this.element  = $(element);
    this.callback = callback;
    this.trigger = trigger;

    this.lastValue = this.getValue();
    if (this.element.tagName.toLowerCase() == 'form')
      this.registerFormCallbacks();
    else
      this.registerCallback(this.element, this.trigger);
  },

  onElementEvent: function() {
    var value = this.getValue();
    if (this.lastValue != value) {
      this.callback(this.element, value);
      this.lastValue = value;
    }
  },

  registerFormCallbacks: function() {

Because I'm a fan of both Ruby on Rails and Drupal (yes, Drupal uses PHP), I get a surprising number of visits to my website each day from Google searches that include some combination of the two as keywords. I find this strange because if you know either of the two, you know that they're in two totally separate worlds.

Drupal doesn't expose any kind of API (besides RSS feeds) that Rails could take advantage of, nor does it make sense to create one.

Since Drupal uses PHP, you can't create module for it in Rails. The only way I could possibly think to marry the two would be to create a module that simply puts an iframe on the page and loads it with your Rails app. In fact, it doesn't even have to be a module. It could be a simple page you create with an iframe pointing to your Rails app.

But why in the hell would anyone want to do this? I guess I'm a little short sighted on this issue right now as its hard to see where the two would play nicely with each other, or why you would want them to. If you want to extend Drupal, use PHP. If you want to use Rails, look at Mephisto or Radiant CMS and extend either of those.

One of the projects I'm currently working on uses ActiveReload's LightHouse application for bug tracking. Its a fairly straightforward web application written in Ruby on Rails that sells itself as "Simple to the bone" bug tracking.

This week I was tasked with working on several bugs and went into Lighthouse, ticket number in hand, ready to get started. Once I log in, I navigated to the "Tickets" page and the search form I'm presented with looks like this...

My first inclination was to put the ticket number right into the search box. No go. That didn't work, so I checked out the dropdown to the right of the search box with no sticking out at me. I then moved on to the "help" link at the end of the form where I learned they provide some pretty cool ways to search tickets... by tags, milestone, status, and even provide natural language date-based searched such as "5 days ago" or "since 1 week ago". All of these you can combine to form fairly complex searches. However, I still couldn't find a way to put in a simple ticket number and find my ticket.

In a previous post I raved about the service and support I receive from RimuHosting and their VPS plans. Their service remains unmatched, but I've been using another hosting provider for some other projects that is also very good.

SliceHost.com has been around for maybe a year now. It was quite the buzz when it came out - and apparently is still since setting up one of their VPS plans requires you to wait for up to several months on a waiting list.

What I like about SliceHost is that everything I normally contact RimuHosting to do for me, I can do myself via SliceHost's admin interface. This mainly involves adding RAM or, since I do a lot of playing around on my slices, reinstalling a clean OS. For instance, yesterday, I wanted a fresh start on my RimuHosting VPS with the latest version of Debian. So, after backing up some databases, I submitted a support ticket and it was done. I'm still hugely impressed that I receive responses from RimuHosting within 5 minutes of me sending an email. And, after I confirmed what I wanted to do, it was another 5 minutes before my VPS was entirely rebuilt.

I just finished a project for a friend using Mephisto. I wrote a custom plugin to handle online submittals of appraisal orders that includes an entire admin interface to manage all the drop down boxes you see. The module stores appraisal submittals so you can see them in the admin interface and re-assign them to different appraisers or update their status etc. The module also autmatically emails a copy of the appraisal to the selected appraiser on submission. Its a very targeted module, so I don't plan to release it, but if anyone is interested in the code, I'd be happy to share it. Just shoot me an email.

Working with the Mephisto plugin system was fun and very easy to do. For anyone looking to extend Mephisto through its plugin system, I highly recommend just grabbing an existing module and dissecting its contents as the documentation isn't quite complete.

The new site is being hosted by HostingRails.com. I've been very impressed with the performance so far, and the little support I've required has been handled very quickly. They get a nods up from me for anyone looking for a shared "Ruby on Rails" hosting provider.

I started playing with the Mephisto contact form plugin written by James Crisp and added a very minor modification to allow users to edit the destination email address from the plugin configuration admin section.

mephisto_contact_form/lib/plugin.rb becomes

module Mephisto
  module Plugins
    class ContactForm < Mephisto::Plugin
      author 'James Crisp'
      version '0.1'
      
      option :destination_email_address, "Enter your address here"
    
      public_controller 'ContactForm', 'ContactForm'
      add_route 'contact_form', 
                    :controller => 'contact_form', 
                    :action => 'contact_form'
      add_route 'contact_submit', 
                    :controller => 'contact_form', 
                    :action => 'contact_submit', 
                    :conditions => { :method => :post }

    end
  end
end

and mephisto_contact_form/lib/contact_notifier.rb becomes

class ContactNotifier < ActionMailer::Base
  include Mephisto::Liquid::UrlMethods
  
  self.template_root = File.dirname(__FILE__) + '/views'
  
  def contact_notification(contact_message)
    recipients      Mephisto::Plugin['ContactForm'].options['destination_email_address']

I thought I might find a short snippet, plugin, gem, whatever, somewhere on the web that would translate my request URI into a simple breadcrumb. Unfortunately, I didn't find anything within the first several pages of the several different Google searches I performed, so I thought to myself, "How hard could it be?". Not hard at all actually. (Still harder than copying someone else's code though.. hehehehe.)

So, here it goes. My requirements were:

1. Breadcrumb nodes should be listed in an unordered list
2. The first node in the trail should always be the "home" link.
3. The last node in the series should not be clickable - since we're already on that page.
4. In the case of an edit, show, or any other action where the id param was stuck onto the end of the URL, I didn't want that id as part of my breadcrumb trail, thus making the action name the last node in the list - and unclickable per #3 above.
5. Any other query string params (e.g. http://url/?variable=value) obviously should not wreak havoc on my breadcrumbs either.
6. Translate all underscores "_" into spaces.

Now, I realize its pretty crude at this point. It appears to be working for what I need it for. Hopefully someone else finds this and can make it better in some way.

<ul>

UPDATE 10/2007: If you're looking to do pagination, the new recommended way is to use the will_paginate plugin.

The new Paginator Gem by Bruce Williams is a much welcomed replacement to the built in Rails pagination mechanism. I've been toying with it now for a few weeks and it works great.

In the spirit of DRY, I've created a global paginator partial to handle paging throughout my application. This partial assumes that you've used the Paginator as per the documentation.

Here's the code for the partial:

I recently finished up a feature that required a search to find all zip codes within a specified number of miles. I've worked with geo-coding before, but fortunately I was able to leave all the hard math to an already existing API (Google Maps, Yahoo Maps, etc.). However, for this project, we couldn't use an existing API and, fortunately, I found the math to be pretty simple.

There were several ways to approach this problem, all of them with varying degrees of complexity. The more complex the algorithm, the more accurate the search would be, but accuracy is also a trade-off for performance. I settled for the easiest and quickest route possible which is a simple box search.

Basically, with the box search, you take the geocode of your search zip code as the center point, convert the radius of your search into degrees latitude and longitude and then add/subtract degrees latitude and longitude to find the four corners of the container box. Once you have the four corners of the box represented in geocodes you can perform a simple search against your table of zip codes with their related geo codes to come up with a fairly accurate result set. (See example below)

There are 2 obvious problems with this search, one of which can be circumvented fairly easily in rails.

I've been through the gamut of web hosts. I started on a shared host when I was using ASP.NET with Microsoft and SQL Server. The site worked and support was ok, nothing to brag about. I soon found out that my host couldn't support what I was wanting to do (host an open-source CMS called DotNetNuke) so I soon switched to another host that would. Things worked fine, but my sites always just seemed a bit sluggish.

I soon learned that if I wanted things to work exactly how I wanted them, I had two choices: 1) Buy a server and all the software that goes along with it and house it in a colocation facility somewhere (too expensive for me at the time), or 2) find a dedicated server hosting plan where I can do what I wanted to the server to make it run optimally for what I was doing. So, I chose option 2 and found a local company that, I must say, did a great job - CrystalTech.