Talk Like A Duck: Category rails

Rails 2.1RC1 and the Enhanced Migrations Plugin

Rick DeNatale — Thu, 15 May 2008 15:24:00 -0400

At work, we use the Revolution on Rails enhanced_migrations plugin.

Yesterday I started the work of moving the app to Rails 2.1RC1.

With version 2.1, Rails is moving to timestamp based migration names, instead of the traditional sequence numbering. This effectively does the same thing as the enhanced_migrations plugin, but the implementation is slightly different, more on this in a bit.

After installing or gitting Rails 2.1 into my vendor/rails directory, I ran the rake task to run all of our tests and specs.

Early on this task does a rake db:migrate, which attempted to run ALL of our migrations since Rails 2.1 looks in a different place to determine if a migration has been already run.

Implementation Differences

Until now Rails has tracked migrations using a single row, single column table in each database called schema_version. This table holds the number of the latest migration which has been run.

The enhanced_migrations plugin uses a w table, named migrations_info, with one row for each migration which has been applied to the database. The key used for this table is the migration number which the migration generator sets to Time.now.to_i. The only column besides the id is created_at. So the enhanced_migration plugin captures the time at which the migration was run against the database, which is different than the time it was generated.

Rails 2.1 uses a table called schema_migrations, which also has a row per applied migration, but this table has a string key whose value is the migration number, in Rails 2.1, the migration number is also a utc timestamp but is a string in the the form “yyyymmddhhmmss”

Blake Watters and I noticed that the timestamp forms can’t overlap since enhanced migrations uses a 10-digit timestamp and Rails 2.1 uses a 14-digit one. So we wrote a new migration 1_convert_migration_schema_to_rails21.rb

class ConvertMigrationSchemaToRails21 < ActiveRecord::Migration
  def self.up
    values = select_values('select id from migrations_info')
    values.each {|value| execute("replace into schema_migrations VALUES('#{id}')")}
  end

  def self.down
  end

We then ran rake db:migrate:up VERSION=1

This populated schema_migrations so that it now “knew” that all of our current migrations had already been run.

Not quite there

For many current users of enhanced_migrations, this might be enough. In our case it wasn’t. When I tried to run rake test again, it blew up in the prerequisite task db:test:clone_structure, complaining about bad sql syntax on an insert statement. The insert statement which was logged looked perfectly fine. It was the second of a series of statements inserting rows into our new friend, the schema_migrations table. The SQL in question looked like this:

INSERT INTO schema_migrations (version) VALUES ('0');
INSERT INTO schema_migrations (version) VALUES ('1');

Followed by a similar line for each of our 500 or so migrations.

The rake task for db:test:clone structure, basically breaks the file db/development_structure.sql into chunks delimited by empty lines, and ‘plays’ them against the test database using ActiveRecord::Base.connection.execute. After some head scratching over why this seemingly legal SQL was being rejected, it occurred to us that it was trying to execute all of these lines as one sql statement.

So the next step was to figure out how to get db/development_structure.sql into a form which would cause the task to execute each sql statement individually. This was a simple patch to rails, which once made, allowed rake db:test:prepare to run successfully, which in turn allowed me to actually move on to running the test suite and working out the problems caused by the changes to rails.

I opened up ticket #201 on the Rails lighthouse which contains the Rails patch.

It's About Time!

Rick DeNatale — Wed, 23 Apr 2008 16:17:00 -0400

The third edition of Agile Web Development With Rails is now in Beta.

Sam Ruby has become the third author, along with Dave Thomas and DHH. According to PragDave, Sam has converted the Depot App tutorial to be compatible with Rails 2, and the rest of the book is also being revised.

Rails Integration Test File Upload Plugin

Rick DeNatale — Fri, 18 Apr 2008 18:07:00 -0400

Some time ago, I wrote a rails patch which allows http file uploading in integration tests.

You just use the same TestUploadedFile class used in functional tests or controller specs if you’re an RSpec’er. So you can do something like.

    post '/upload' :file => TestUploadedFile("/path/to/blah.txt")

The patch detects a TestUploaded file amongst the parameters, and converts the request into a proper multi-part request.

It will work for both posts and updates.

If you’re running edge rails you’ve already got this. But many have asked for a version for earlier rails versions. At work, I’ve been working on an RSpec story which requires file uploading, and we’re using the 2.0.2 gem version of Rails for deployment purposes, so I whipped up a little plugin which patches 2.0.2 Rails with the changes from Rails changeset 8978. The plugin checks the rails version and throws an exception if it’s anything other than “2.0.2” since I haven’t tried this with anything earlier, and it’s not necessary for anything newer.

You can get it from git hub at git://github.com/rubyredrick/integration_upload_plugin.git

This also marks the first time I’ve used git for anything but gitting Rubinius.

RSpec Anti-Pattern - Don't Set @controller yourself

Rick DeNatale — Wed, 26 Mar 2008 17:30:00 -0400

I was adding to an existing controller today at work and I was stumped because one of the examples in its controller spec was failing due to an exception thrown while rendering a view.

Normally RSpec controller tests, which are usually used to specify controller logic, bypass view rendering unless you specifically use the integrate_views method in the example group. The idea is that you should use view specs to specify the logic and output of views.

Since I was working in existing code, which pre-existed my being here, I’d followed some of the existing example groups in the file. These would typically look something like this:

describe HobbitController, "doing something" do

    before(:each) do
      @controller = HobbitController.new
      #.. more setup stubbing etc.
    end

   #examples
end

I finally realized that that first line in the before block was clobbering RSpecs ability to control whether or not views should be rendered. RSpec actually creates the controller instance variable for you, and extends it with a module which overrides the render method to allow integrate_views to control the rendering while allowing the expect_render expectation to work whether or not rendering actually happens.

So I’ve got a new task to clean up all the other controller specs.

Validating RSS Feeds with RSpec

Rick DeNatale — Fri, 08 Feb 2008 10:38:00 -0500

One of my current Rails projects involves generating an RSS feed. While I was working on this the other night, it seemed to be working, so I deployed it to the staging server. Everything looked fine. If I fetched it with Firefox, the browser offered to let me subscribe to the feed with Google Reader, and if I used Safari I'd see a nice view of the feed just like I expected.

So I sent a note via our campfire to check it out, and a colleague replied that his Safari was saying that it was in an invalid format.

So I went to the W3 RSS Feed Validation Service and worked through the validation issues, after which his browser was as happy as mine.

Of course, having been through that, I wanted to make sure that RSS validation was covered in the specs for the project.

I went looking for an existing RSpec matcher, and found a matcher to validate XHTML but nothing for RSS.

I then found the feedvalidator gem which provides a Ruby interface to the SOAP interface to the W3 feed validator. You would think that W3 would be providing a REST interface! The gem already provides assertions for use with Test::Unit, so I just built an RSpec matcher.

class BeValidFeed
  require 'feed_validator'
  require 'tmpdir'
  require 'md5'

  def matches?(response)
    return true if validity_checks_disabled?
    v = W3C::FeedValidator.new()
    fragment = response.body
    filename = File.join Dir::tmpdir, 'feed.' + MD5.md5(fragment).to_s
    begin
      response = File.open filename do |f| Marshal.load(f) end
      v.parse(response)
  	rescue   
      unless v.validate_data(fragment)
        @failure = " could not access w3 validator to validate the feed."
        return false
      end
      File.open filename, 'w+' do |f| Marshal.dump v.response, f end
  	end
    v.valid?   
  end

  def description
    "be valid xhtml"
  end

  def failure_message
   @failure || " expected xhtml to be valid, but validation produced these errors:\n #{@message}"
  end

  def negative_failure_message
    " expected to not be valid, but was (missing validation?)"
  end

  private
    def validity_checks_disabled?
      ENV["NONET"] == 'true'
    end
end

def be_valid_feed
  BeValidFeed.new
end

I saved this as spec/be_valid_feed.rb

And in a view or controller spec, I can include this file, and test a response with:

response.should be_valid_feed

If you use this in a controller spec, you will need to tell RSpec to integrate_views, or you won't have much of a feed to check. If you use nested example groups, integrate_views needs to be inside the inner group.

Why I Don't Mind Using RSpec - In Fact I've Come to Love It.

Rick DeNatale — Tue, 29 Jan 2008 16:24:00 -0500

About a year ago when I first encountered RSpec, I thought that the idea sounded good, but I was concerned about how much the implementation at that time pushed new methods into Object and Kernel. It felt to me as though it could interfere with the code being specified/tested. Indeed back then there were some problems when RSpec and Rails bumped heads over the use of certain Ruby metaprogramming techniques. I’d been a TDD user advocate for many years, heck I was there right after Kent Beck, “test-infected” Erich Gamma and sat in on some of their early pairing sessions during an annual OTI company technical conference at Montebello in Quebec, when JUnit was in it’s infancy. The cleaner language of RSpec did have it’s attractions, particularly in trying to get across the idea to newcomers that TDD was really writing mini-specifications rather than tests, which helps put them in the right mindset, but for those of us who had already crossed that paradigm shift, or been born on the right side of it, it didn’t seem so important.

Since then the RSpec implementation has matured, and after talking to David Chelimsky and Dave Astels at RubyConf, I decided to give it another look, and, armed with a new perspective on the use of mocks and stubs to isolate specifications and tests in BDD/TDD, I quickly became a convert. I still use other frameworks as external requirements dictate, but RSpec has become my first choice.

These days, though the choice of testing/specification framework seems to have become one of those religious issues which divide the community, almost as much as emacs vs. vim vs. textmate. I run into people all the time who reject RSpec because it’s “too magical!” Although I’ve never been able to get them to expand on that thought. Perhaps it’s based on the kind of concerns I had about it at first, maybe it’s something else. I’d love to have it explained.

And like advocates do, other arguments get expressed, some of which don’t get the scrutiny they deserve.

For example, a few days ago Rob Sanheim, someone I know and respect, wrote about why he eschews RSpec for Test::Spec. His basic, quite brief argument is that because RSpec is 10 times bigger in terms of lines of code than Test::Spec it must be worse.

How to Lie with Statistics

Nice statistics, but back when I was in college, one of the must-read books was “How to Lie with Statistics”. Given the right pick of statistics you can prove anything.

First off I think that Rob was unfair to lump the lib and spec or test directories together. Even if you might believe that code bulk is bad, I think that it’s reasonable to think of the code bulk in the implementation to be like ‘bad cholesterol’, and test-code which verifies that implementation as ‘good cholesterol.’ Most of you are probably too young to be concerned about it yet, but my doctors tell me that a high HDL/LDL ratio is more important than an absolute HDL+LDL. The theory at least is that the HDL helps sweep the LDL out of the vessels, kind of like a good test suite keeps code under control.

Here are the numbers I get running sloccount on the latest RSpec and test/unit gems:

Framework	lib	spec/test	test/code ratio
Rspec	5473	10108	1.8
Test::Spec	275	879	3.2

So at first blush it looks bad for RSpec, Test::Spec even tests itself more thoroughly!

The real problem with Rob’s post is that he’s comparing Apple seeds with Apples. Of course Test::Spec is considerably smaller than RSpec, it’s a bump on Test::Unit to add the new assertion style. So we need to at least add Test::Unit’s numbers

Framework	lib	spec/test	test/code ratio
Test:Unit	2741	0	0

Now I’m sure that Nathaniel “ate his own dog food” when he developed Test::Unit, and Ryan is continuing to dine on it, now that he’s taken over its maintenance, but that dog food apparently doesn’t leave home. Now if we look at the combination of Test::Unit and Test::Spec the comparison looks like this:

Framework	lib	spec/test	test/code ratio
Rspec	5473	10108	1.8
TU+TS	2713	879	0.3

So RSpec looks a little better, particularly when it comes to eating it’s own dog food.

But, as that Billy Mays guy on the Infomercials is wont to say, “Wait! There’s more!”.

RSpec also includes a built-in mocking framework, now with the ‘traditional’ choice you need to throw in your choice of mock framework, here’s are the stats for Flexmock and Mocha

Framework	lib	spec/test	test/code ratio
Flexmock	1034	2743	2.6
Mocha	1218	3622	2.8

So now we’ve got two sub-variants to look at:

Framework	lib	spec/test	test/code ratio
Rspec	5473	10108	1.8
TU+TS+FM	3747	3622	1.0
TU+TS+Mocha	3931	3931	1.1

Now you might say that RSpec still is 40% larger than even the larger of the two competing combinations, but this is also ignoring the fact that RSpec also includes RBehave which is another higher level integration/acceptance testing framework.

So in retrospect, I’d humbly submit that code bulk isn’t such a good comparison criteria in this case.

So whatever your test framework ‘belief system’ do as you feel best, but do unto others!

I’d still like to hear more about why people think that RSpec is “too magic” though.

By the way on the subject of lying statistics. I’m sure that most of us have by now seen this chart of Ruby job prospects.

Which looks like, and is, GREAT news for Rubyists, but how many have seen this from the same source. It’s the same data, just looked at through a different lens.

I’m still not looking for Java work though!

Book Review: The Rails Way

Rick DeNatale — Thu, 27 Dec 2007 12:57:00 -0500

Disclaimer: I received a free copy of this book because I contributed a one-page essay about "What Rails Means to Me" which appears starting on page 821.

The Rails Way came out shortly before Rails 2.0 was released. I must say that it serves as a very valuable reference for those with some Rails experience, and in particular for those who are coming up to speed on Rails 2.0.

Comprising 850 pages, this tome covers a wide spectrum of Rails and Rails related topics. Although it's been a while since I was a newcomer to Rails, I think it would be a rare newbie who could jump into Rails and learn it by reading this book. Although some sections are written in a tutorial style, it really serves best as a resource for those wanting to increase their mastery of Rails. I've found many thought provoking ideas as I read it.

Obie's approach is to pick an aspect of Rails and talk about how it's put together as a way of providing a more intimate view of the framework. I find this very comfortable, it's kind of a an advanced guided tour.

The book starts out with a walk-through of how Rails starts up, giving the opportunity to explore how Rails configuration works, and how it relates to the various rails environments.

The next four chapters, comprising 101 pages, talk about controllers and routing. There's a lot of valuable information here, particularly with regards to Rails 2.0, and how RESTful controllers, resources, and routing works.

From there, the book moves on to ActiveRecord. Four chapters cover the basics, associations, validations, callbacks, observers, single-table inheritance, and more in 167 pages, a book-length treatment in itself. This is more than the 131 pages on ActiveRecord in Agile Web Development with Rails snd only slightly less than Pro Active Record: Databases with Ruby and Rails which is totally dedicated to ActiveRecord.

This is about as far as I've managed to get through to date, the remainder of this review is based on skimming.

The coverage of ActionView starts with a chapter covering the basics of ERB, tne new naming conventions in Rails 2.0 (e.g. a view named index.rhtml would now be named index.html.erb); layouts, templates and partials; and various aspects of caching in Rails and how to tame it.

Chapter 11 covers helpers. Among other things, Obie covers the popular topic of how to write form views which handle updating multiple objects simultaneously. He covers both built-in Rails helpers as well as those provided by popular plug-ins such as the various pagination plugins. Of course he also covers the niceties of writing your own helpers.

Chapter 12 devotes 48 pages to Ajax on Rails, starting with the very valuable advice to install and use Firebug to debug the resultant Javascript, then covering Prototype and Scriptaculous and their associated helpers, RJS and JSON

Chapter 13 gives us 15 pages on managing sessions, including the latest on Rails 2.0's new CookieStore default for "storing" session data.

Chapter 14 is all about user login and authentication. Seventeen pages are devoted to using Rick Olsen's acts_as_authenticated plugin. This is one area of the book which is already slightly dated, particularly for Rails 2.0, since acts_as_authenticated has been supplanted by Rick's newer restful_authentication plugin, or so some commentary in the acts_as_authenticated plugin itself leads me to believe.

Chapter 15 covers XML in 26 pages. The ability to produce and consume XML is part and parcel of fully supporting REST in Rails and the use of ActiveResource. Obie also covers how to generate XML, and the use of the Builder framework; parsing XML using the XMLSimple library built in to Rails; leading up to an exposition of ActiveResource.

ActionMailer gets it's due in Chapter 16.

Testing, and test-driven development gets two chapters. The 51 pages in Chapter 17 cover "classical" Rails testing using Test::Unit, while Chapter 18 adds another 30 pages on RSpec and the RSpec on Rails plugin.

Chapter 19 covers plugins from multiple aspects: managing them with the script/plugin command, keeping them under version control with subversion and Piston; and a basic overview of how to write your own plugins.

The last three chapters cover deployment. Chapter 20 discusses the Rails deployment landscape covering the requirements for a Rails "Stack"; the installation and configuration of various stack components (Ruby, RubyGems, Rails, Mongrel, MongrelCluster, Nginx, Subversion, MySQL, Monit, and Capistrano); writing init scripts for Mongrel, Monit, and Nginx; and a very brief overview of production stack considerations related to performance, reliability and security.

Chapter 21 covers Capistrano 2.0 in 25 pages, while Chapter 22 wraps up with 16 pages on background processing.

Finally, there are two appendices. Appendix A covers ActiveSupport, and Appendix B is a catchall for useful things Obie thinks every Rails developer should know, but didn't have another place in the book.

Conclusion

This book, as I said before, is a tome like Hal Fulton's The Ruby Way, also in the Addison-Wesley "Professional Ruby Series." While both suffer from minor editing omissions and mishaps, "The Rails Way" seems to be a bit more polished, and Obie has set up a lighthouse site for tracking errata.

All in all I heartily recommend The Rails Way as a resource for Rails developers wanting to move on from white or green, to black-belt status.

Book Review: Pro Active Record

Rick DeNatale — Tue, 30 Oct 2007 12:31:00 -0400

I've been meaning to write a review of the recently published Apress book "Pro Active Record" by Kevin Marshall, Chad Pytel, and Jon Yurek for a while now. I have to admit that I was prompted to sit down and actually do it after reading Josh Susser's recent review of the same book.

While I generally agree with Josh's assessment, We do differ a bit on which audience the book best serves.

The goal of the book is to cover Active Record in depth, outside of the context of Rails. The result, as I see it, is a book which is useful to intermediate to advanced users of Active Record, those who want to dig in to understanding the implementation and perhaps extending it.

My own reading of the book gave me the impetus to explore the code of Active Record to the extent where I felt comfortable submitting contributions to Rails. Since reading the book, I've written and submitted two active record patches to the Rails Trac. The first fixed an oversight which made the schema.db file dumped for MySQL tables with non-standard primary keys to lack those primary key declarations, and the second is an enhancement which allows the :joins option of methods like find and count in ActiveRecord::Base to take values like the :include option as an alternative to a sql joins clause string. Both have made it into rails edge!

Pro Active Record for Beginners?

While I suppose that you could learn Active Record just from this book, I personally think that Agile Web Development with Rails (2nd ed) does a better job, and makes a better reference for everyday use of Active Record. While not entirely devoted to Active Record, AWDWR devotes four chapters and 131 pages to it in the "Rails in Depth" section of the book, in addition to coverage of AR in the tutorial section. In contrast, "Pro Active Record" comprises 8 chapters in 214 pages, plus a 52 page Appendix which is pretty much derived from the RDoc generated from the Active Record source code.

Shortly after I bought the book, I was working on an issue with some active record validation callbacks on one of my projects. Since "Pro Active Record" was at hand I turned to it. Although they have good coverage of the topic in Chapter 4, "Core Features of Active Record", the five pages of text description in PAR just doesn't make it as clear when particular callbacks will be called as the single chart on page 372 of the "Object Life Cycle" chapter in AWDWR.

While some newcomers to active record who are using, say Camping, might welcome the "Rails-free" presentation of PAR, sometimes I get the impression that studiously eschewing Rails in this book hampers it just a bit. There sems to be a little too much repetition of things that Rails does for you, like ActiveRecord::Base.connect(...)

Digging In

That said, I do really like the book. The chapter on dealing with legacy databases is quite useful, and I'd recommend it.

The best part of the book was the section on extending AR. It gives a good introduction to the way AR works, it got me started actually reading the AR code in edge rails. It also gives some good coverage of Ruby metaprogramming, particularly in the context of AR and Rails

Summary

So all in all, I recommend the book, although I would recommend newcomers to start with Agile Web Development with Rails (2nd ed) even if they are using AR outside of rails.

Those who are, or want to be, a little further along in their exploration, exploitation, and extension of Active Record will find it to be a valuable addition to their book shelf, just as I did.

My First Serious TextMate Automation

Rick DeNatale — Tue, 09 Oct 2007 08:15:00 -0400

I recently got assimilated by the Mac/TextMate borg. I'm slowly teaching my fingers to dance the TextMate tango and unlearning old vim habits.

One resource has been James Edward Gray II's book on TextMate published by the Pragmatic Programmers. I finally sat down and got serious about writing some automations of my own.

I've got to say that I'm pretty impressed by TextMate. At the last Raleigh.rb hack night I was talking to another vim user. I'd mentioned to him that you can extend TextMate easily in Ruby, without really having experienced it. Today, I wrote a neat little TextMate command to help in building Rails database test fixtures.

It acts like a tab triggered snippet, but it's a smart little critter. If I'm editing a fixture file, say 'test/fixtures/users.yml', I can type item then tab and it will produce the skeleton yaml for a new record, with:

A dummy name selected for overtyping.
The id set to the next available primary key
... A tabstop on a value which shows the column type

For example:

Suppose I've got a fixture file for a model called Item:

	# == Schema Information
	# Schema version: 14
	#
	# Table name: items
	#
	#  id          :integer(11)   not null, primary key
	#  description :string(255)   
	#  name        :string(255)   
	#  price       :integer(11)   
	#

	# Read about fixtures at http://ar.rubyonrails.org/classes/Fixtures.html
	lotr1:
	  id: 1
	  name: LOTR1
	  description: The Road Goes Ever On
	lotr2:
	  id: 2
	  name: LOTR2
	  description: Introduction to Elvish

If I type a new line at the end of this file with the snippet command item and hit tab I see this:

lotr2:
  id: 2
  name: LOTR2
   description: Introduction to Elvish

  NameMe:
   id: 3
   description: string
   name: string
   price: integer

With NameMe selected so that I can easily replace it by typing. Note that the id was set to 3 since rows with ids 1 and 2 already exist.

Hitting tab again selects the first instance of string, and subsequent tabs step through the columns

Another feature which I won't show is that it looks at the table and if it doesn't have a primary key (e.g. for an association table in a has_and_belongs_to_many association), it won't generate the id: or a key.

You might be impressed, but I'm pretty happy with the results of a couple of hours of playing with TextMata and Ruby.

How it works.

The whole thing is done with a TextMate command implemented in Ruby. A few notes. First, it's just a coincidence that the snippet trigger is item and my example table is called items. Second, I'm not using the comments at the top of the fixture file which were generated when the model was created. The command works off of db/schema.db.

Here's the code:

	#!/usr/bin/env ruby -w  
	#
	#  Created by Rick DeNatale on 2007-10-09.
	#  Copyright (c) 2007. You may use this under the ruby license.                    

	$LOAD_PATH << "#{ENV['TM_SUPPORT_PATH']}/lib"
	require 'exit_codes.rb'


	class FixtureSnipGen
	  attr_reader :rails_root, :table_name
	  def initialize(fixture_file)
	    match  = %r{(.*)test/fixtures/(.*).yml}.match(ENV["TM_FILEPATH"])
	    @rails_root = match[1]
	    @table_name = match[2]
	    @no_id = false  
	  end

	  def next_id
	    max_id = 0     
	    while line = gets
	      claimed = %r{\s+id:\s+(\d+)}.match(line) 
	      max_id = [max_id, claimed[1].to_i].max if claimed
	    end
	    max_id + 1
	  end

	  def gen_snippet
	    cols = gen_columns
	    if cols
	      puts "${1:NameMe}:"
	      puts "  id: #{next_id}" unless @no_id
	      puts cols.join("\n")
	    else 
	      puts "Couldn't find #{table_name} in schema.rb"
	      TextMate.exit_show_tool_tip
	    end
	    puts "$0"
	  end

	  def schema_file_name  
	    "#{rails_root}db/schema.rb"
	  end 

	  def value_tab(text)
	    @tab_stop += 1
	    (@tab_stop < 10) ? "${#{@tab_stop}:#{text}}" : " # #{text}"
	  end


	  def gen_columns
	    #    raise Exception.new("No schema file") unless File.exist?(schema_file_name)
	    started = false
	    @tab_stop = @no_id ? 0 : 1
	    result = []
	    File.new(schema_file_name).each do | line |
	      if started
	        break if %r{^(\s*)create_table\s+}.match(line)
	        col_match = %r{\.column\s+\"(.*)\"\s*,\s*:(\w+)}.match(line)
	        result << "  #{col_match[1]}: #{value_tab(col_match[2])}" if col_match
	      else
	        started = %r{^(\s*)create_table\s+["']#{table_name}['"]}.match(line)
	        @no_id = %r{:id\s+=>\s+false}.match(line) if started
	      end
	    end
	    return result.empty? ? nil : result    
	  end
	end

	begin
	  FixtureSnipGen.new(ENV["TM_FILEPATH"]).gen_snippet
	rescue Exception => ex
	  puts ex
	  TextMate.exit_show_tool_tip
	end

In the TextMate bundle editor, I just added a new command with this code, and set the following options:

Save:: Nothing
Input:: Entire Document - which pipes the entire textmate buffer for the file into stdin.
Output:: Insert as Snippet - which triggers TextMate to interpret the output as a snippet once the script has finished.
Activation:: Tab Trigger = item
Scope Selector

Finally note that although my example uses a table called items, it's just a coincidence that the tab trigger is item. It would be item in any fixture file.

Observing Fields With Rails in the Browser

Rick DeNatale — Sun, 07 Oct 2007 12:34:00 -0400

The AJAX support in Rails is great, but sometimes you don't want to have to make an unnecessary trip to the server to make your UI dynamic. For example, let's say you want to do something like Basecamp does when you create a new message. If you have a Basecamp setup to allow you to talk to both members of your team and also clients, it provides some nice checkboxes to let you control who will get notified of the new message. Those checkboxes are grouped with a checkbox for each company, and then checkboxes for all of the people from that company below the company checkbox. If you check or uncheck a company checkbox all of the people listed under the company are checked or unchecked to match.

This can all be done within the browser. It just requires manipulation of existing elements within the domain object model, so there's no need to go back to the server.

Rails provides the observe_field helper method which is normally used to generate a remote request when a DOM element changes. It can be used to do what we want, but how to do so isn't well documented, either in the Rails documentation, or via google.

So here's how to do it.

What the Rails Doc says

Here's how the official doc for observe_field starts...

observe_field(field_id, options = {})
Observes the field with the DOM ID specified by field_id and calls a callback when its contents have changed. The default callback is an Ajax call. By default the value of the observed field is sent as a parameter with the Ajax call.

Required options are either of:

:url: url_for-style options for the action to call when the field has changed.

:function: Instead of making a remote call to a URL, you can specify a function to be called instead.

So the function option seems to be what we need When I read this I assumed that the value should be a string containing a javascript function definition. But it's not.

What the value should be is javascript code for the body of the function definition. The prototype helper provides the surrounding definition. So when you code:

        
observe_element('company1', :function => 'code')

The javascript code generated looks like:

Form.Observer.new('company1', function(element,value) {code})

So just write Javascript code for the body. You can use the element parameter to refer to the domain element being observed, in this case it would be the same as the prototype expression "$('company1')" and the value parameter gives you the value attribute of the observed element.

So let's say our company has two guys whose checkboxes are 'bill_c' and 'sam_r' and our company checkbox is called 'our_corp'. Then this helper call:

        
observe_element(
    'our_corp', 
    :function => "$('bill_c') = value\n$('sam_r') = value")

Should do the trick of turning both the bill_c and sam_r checkboxes on or off when we toggle the our_corp checkbox.

Of course you probably don't want to hand code the ids, and the actual ids will conform to those used by the form helpers, but I'll leave those details to you

Getting the Rails Docs Updated

I've submitted a ticket on rails trac with a patch to document this. If you've got a rails trac account, please have a look and consider adding a +1 to get this into report #12 and into Rails.

`:url`:	`url_for`-style options for the action to call when the field has changed.
`:function`:	Instead of making a remote call to a URL, you can specify a function to be called instead.