Turns out the mouse wheel would stop working after a switcharoo.  It took me a little while to track down the solution on the Ubuntu forums.  There was a lot of back and forth in the comments, but this is the dead-simple solution:

Ensure the psmouse module is loading

Edit and add the following line to /etc/modules:

psmouse

You’ll need to use sudo (i.e. sudo vi /etc/modules).

Set the imps option for the module

As sudo user, edit /etc/modprobe.d/options and append the following:

 # Make my mouse work with KVM
 options psmouse proto=imps

Reload the mouse module

Once you have the above, issue the following commands:

 # sudo modprobe -r psmouse
 # sudo modprobe -a psmouse

Once you do this, you should have a functioning mouse wheel. Test it out before and after switching machines with your KVM hot keys.

Thanks to the contributors of the Ubuntu Forums for this.

A little background…

Our shop has been using virtual technologies for just over two years. At the time we started taking it seriously, the open source offerings were just on the cusp of being production quality; Citrix had not yet bought into Xen; and VMWare had just rolled out their free VMWare Server option.  We had a mixture of Linux and Windows servers, all physical, and were really feeling some of the budget pince in our rapid growth. We decided it was time to rethink how we were growing our data-center and that led us to try out VMWare and Xen side-by-side, eventually siding with Xen since the bulk of our servers turned out to be Linux hosts while our predominant application, SQL Server 2005 was not all that conducive to being virtualized without some heavy, heavy investment in hardware purchases.

The gameplan, get some beefy servers, run Xen on them, with images residing on SAN and migrate all our physical Linux hosts to virtualized environment. Once converted, we’d simply reclaim all the excess hardware to fuel the Windows SQL Server hunger.

So, off we went. We purchased a three of Dell’s first dual quad-core servers at 1.66ghz and loaded them up with 16gb of RAM and a Dell AX150i iSCSI dual storage processor SAN to run our wonderfully envisioned HA cluster off of.

Xen had just turned 3.0 at the time and we really went through a lot of permutations in our stress testing and daily use before we finally came up with a stable blending of several offerings from the open source community. As wild as it may seem, we settled on Oracle VM’s first release as the Xen server, CentOS 5 repositories to manage packages on the host, Red Hat’s kickstart project to build the VM’s and ran a mixed guest environment of CentOS 4, CentOS 5, and Fedora Core 8. The guest environment’s heterogeneity had a purpose for existing. You see, our clients often dictated what version of Red Hat they wanted us to support when we deployed our systems in their data center, so we needed these three items (all relatively free of compulsory licensing fees) to give us the ability to effectively emulate any of our clients’ data center in-house for Q/A, stress/load, and deployment “dry-run” testing purposes.

After trying for many moons to effect a HA clustering solution that was rock-solid and backed by the SAN, we sadly had to regress from that vision (for now). VM images that were once all homed on the SAN and connected via iSCSI to the Xen hosts simply overwhelmed our SAN with I/O dropping low enough to force the filesystems of the guests into read-only state. We gave up the HA vision (for now) and purchased a bunch of very fast SCSI drives and RAID 5′d them, filling up each of the Xen Host’s drive bays and relocated the VM images to each Xen host’s local volumes.

This infrastructure has been our “norm” for the better part of the year now and we have a rock-solid deployment running about 80 virtualized Linux hosts on just four Dell servers. The ease with which we can set up a new server or tear one down and dismiss it has had quite an effect on our ability to test widely varying deployment scenarios and automate the deployments themselves.

Fast forward October 2008

The newest version of Xen from Red Hat (and hence CentOS for us) is looking rather sharp. Virtually all the issues we were encountering with just standalone Xen hosts appear to be addressed (in our limited testing). One of the more critical one, where our Dom0 environment would become unstable and we’d lose ability to manage it has been fixed (our lone-remaining headache in the above setup). We have not, however, ventured to test whether our HA woes have been resolved as well. One other thing we did notice, though was that VM guests shutdown and launch a whole lot faster than they do on our production servers, so that could hint to some very good performance improvements lurking in the newest releases of Xen.,

The downside: Six, yes count ‘em, six CDs must be downloaded to install the CentOS Xen version. Oracle VM, by comparison clocks in at roughly ONE 500mb CD image plus two companion CDs that give you their VM Manager and some other handy tools that go hand in hand with managing a Virtual Server environment. Oracle wisely dispenses with all the developer tools and Gnome desktop and office productivity tools that bloat up the RHEL/CentOS distros. Good security practices recommend only running what you need to run on your server and nothing else!

What follows below is how to get your first Virtualized server up and running by downloading just the one Oracle VM Xen Server CD. As far as I know, this is about as simple as it gets. The graphical environment is not used and none of the iSCSI or LVM (logical volume management) tools are employed. This is just a simple exercise that gets your hands dirty and playing with virtual technologies.

Step 1 - Install the Xen Server

Download the Oracle VM Server 32-bit Edition CD from Oracle and burn the ISO to CD. Then plop it into your CD drive on the machine you want and boot up. Follow the installation instructions on the screen (or the Online documentation). Once installed, boot up and log in as root.

Note: At the time of this writing, we’re installing Oracle VM 2.1.2

You should now be able to issue:

# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   543     1     r-----   3036.7

And see an output similar to the above. Congratulations, you have a Xen Server up and running.

Step 2 - Initial File Preparation for the Guest

Initialize diskspace for your first Virtual Machine by performing the following commands (as root):

# cd /OVS
# mkdir -p local/numberone && cd local/numberone
# mkdir numberone
# cd numberone
# dd if=/dev/zero of=numberone_hda1.img bs=1024k count=6000
# dd if=/dev/zero of=numberone_hda2.img bs=1024k count=1500

This will set up a “local/numberone” folder on the Oracle Clustered File System partition, “/OVS” with first file being 6gb and 2nd file being 1.5gb. These will then become root partition and swap space of the guest VM, which we’re calling “numberone” here (you can name it any valid hostname you desire). Once these files are established, we create the filesystems for them with:

# mkfs.ext3 numberone_hda1.img
# mkswap numberone_hda2.img

Step 3 - Establish the Root partition of the Guest

Its time to push some files onto the root partition so that we have a valid system that can boot. Begin by issuing the following statements:

# cd /OVS/local/numberone
# mkdir hda1
# mount -o loop numberone_hda1.img hda1
# rsync  -avH /boot hda1
# rsync  -avH /root hda1
# rsync  -avH /dev hda1
# rsync  -avH /var hda1
# rsync  -avH /etc hda1
# rsync  -avH /usr hda1
# rsync  -avH /bin hda1
# rsync  -avH /sbin hda1
# rsync  -avH /lib hda1
# rsync -avH /selinux hda1
# mkdir hda1/{proc,sys,home,tmp}
# chmod 777 hda1/tmp
# unmount hda1
# rmdir -rf hda1

Step 4 - Configure the Guest

You really don’t want the guest OS coming up with the same configuration as your Xen Host, so lets get into the guest’s /etc folder and do some tweaking:

Edit /OVS/local/numberone/hda1/etc/fstab and set the root and swap partitions

/dev/hda1               /                       ext3    defaults        1 1
/dev/hda2               swap                    swap    defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0

Edit /OVS/local/numberone/hda1/etc/sysconfig/network and change the hostname

NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=numberone
GATEWAY=192.168.0.5

Note: Gateway is the firewall on your network providing Internet connectivity. Mine happens to be 192.168.0.5.

Edit /OVS/local/numberone/hda1/etc/hosts and change the hostname

127.0.0.1               numberone localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6

Rename /OVS/local/numberone/hda1/etc/sysconfig/network-scripts/ifcfg-eth0 to /OVS/local/numberone/hda1/etc/sysconfig/network-scripts/ifcfg-eth0.bak so its not used when the guest first boots up.

Similarly, rename /OVS/local/numberone/hda1/lib/tls to /OVS/local/numberone/hda1/lib/tls.disabled

Then unmount the guest’s root partition:

# cd /OVS/local/numberone
# umount hda1

Create a domain configuration file for your new guest in /etc/xen/numberone on the Xen Server (not the guest’s root partition):

#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or
# you can set the parameters for the domain on the xm command line.
#============================================================================

#----------------------------------------------------------------------------
kernel = "/boot/vmlinuz-2.6.18-8.1.15.1.16.el5xen"
ramdisk = "/boot/initrd-2.6.18-8.1.15.1.16.el5xen.img"
memory = 512
name = "numberone"

vif = [ 'bridge=xenbr0' ]

disk = ['file:/OVS/local/gox/gox_hda1.img,hda1,w',
        'file:/OVS/local/gox/gox_hda2.img,hda2,w' ]

root = “/dev/hda1 ro”

# Sets runlevel 4.
extra = “4″

The mac address was left out of the vif definition. We’ll boot up the guest to console and see what “reasonable value” the Xen host establishes for the server then come back and hard code the value so its not changing all the time.

Step 5 - Booting for the first time

To boot the guest, we’ll use the command-line tools, specifically “xm” to create (boot) the guest and shutdown rather than the Oracle VM Manager. So lets have a look:

# xm create -c numberone

The “-c” flag boots you with console view of the guest. If all went well, you’ll see a typical Linux boot up process that leads all the way to a login prompt similar to this:

Oracle VM server release 2.1.2
Hypervisor running in UNDETERMINED bit mode (WARNING: XEND IS PROBABLY NOT RUNNING).

Network :
Management Interface  :
If : eth1(Down)  Mac :  IP address : 

Configured Networks and Bridges :
If : eth0	 Mac : 00:16:3E:22:F3:4F

CPU :
cpu family	: 15
model		: 31
model name	: AMD Athlon(tm) 64 Processor 3200+

numberone login:

Copy that Mac address to clipboard (or write it down) because you’re going to need it for the next steps. Log in as root, same password as the Xen Host (since we copied everything off the host to begin with!).

Edit /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:3E:22:F3:4F
ONBOOT=yes
IPADDR=192.168.0.150
NETMASK=255.255.255.0

Once you’ve done this, you should be able to start your network and ping your gateway:

# ifup eth0
# ping 192.168.0.5
PING 192.168.0.5 (192.168.0.5) 56(84) bytes of data.
64 bytes from 192.168.0.5: icmp_seq=1 ttl=64 time=3.33 ms
64 bytes from 192.168.0.5: icmp_seq=2 ttl=64 time=1.04 ms

If not, check for typos. Otherwise, you’re done with configuring the guest. Continue by logging out of your guest then break from console with CTRL-] (control-key plus left-bracket key). Edit /etc/xen/numberone and change the vif line to read:

vif = [ 'mac=00:16:3E:22:F3:4F, bridge=xenbr0' ]

This gels your mac address for the guest VM so the network will be reliably started on reboots for eth0 device. Now issue the following:

# xm shutdown numberone
# xm top

And watch your guest disappear from the listing. Once its gone, issue the following to bring it back up:

# xm create numberone

Finally, if everything’s gone well, you will be able to ssh to the guest VM with:

# ssh 192.168.0.150 -l root

(Hey, I didn’t say it was uber secure or that we’re following best practices regarding root accounts!)

If you can’t ssh into the guest from the xen server, you’ll have to get back into console and review logs and figure out what went wrong. You may need to fix typos in your configs or try another xen bridge such as xenbr1. If you are able to issue “ifup eth0″ within the guest and can ping your firewall, its not network connectivity, but a typo in your /etc/sysconfig/* files somewhere. Probably the best place to double-check things is the mac address.

# xm console numberone

One last tip. If you want to install packages that didn’t come on the Oracle VM install CD, you can add the CentOS5 repository to the VM guest and install various packages using yum thereafter. To do this, log into your Guest VM, and edit the following new file: /etc/yum.repos.d

[CentOS5 base]
name=CentOS-5-Base
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=0
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

[CentOS5 updates]
name=CentOS-5-Updates
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=updates
gpgcheck=0
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

[CentOS5plus]
name=CentOS-5-Plus
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=centosplus
gpgcheck=0
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

So there you have it. One of the simplest approaches to getting your first Xen guest Virtual Machine up and running and well on your way to experimenting with virtual technologies.

Special Note: Much credit must go to my colleague, Manyuan Jin, who spent many, many tireless hours researching early instability issues and treading through the jungle of open source solutions to assemble a working solution for our shop.

The following Browser Edit form is what we’re going for. That is, having a list of Operating Systems to check off while editing a Browser object:

class CreateBrowsers < ActiveRecord::Migration
  def self.up
    create_table :browsers do |t|
      t.string :name
      t.string :version
      t.string :short_name
      t.timestamps
    end
  end

  def self.down
    drop_table :browsers
  end
end

class CreateOses < ActiveRecord::Migration
  def self.up
    create_table :oses do |t|
      t.string :vendor
      t.string :name
      t.string :version
      t.string :short_name
      t.timestamps
    end
  end

  def self.down
    drop_table :oses
  end
end

The Browser and Os table are very straightforward migration scripts. However, pay attention to the next script as we do a couple of interesting things. A) we tell the migration not to create the default ID column and B) we use the t.references declaration in defining our columns.

class BrowsersOses < ActiveRecord::Migration
  def self.up
      create_table :browsers_oses, :id => false do |t|
        t.references :browser
        t.references :os
        t.timestamps
      end
    end

    def self.down
      drop_table :browsers_oses
  end
end

Note that I used the singular version of the model names. I originally used the plural form and got browsers_id and oses_id instead of the expected browser_id and os_id column names.

Which brings me to another issue I encountered. “Os” didn’t pluralize properly, so I needed to add a custom inflector to the project’s config/initializers/inflections.rb file:

ActiveSupport::Inflector.inflections do |inflect|
  inflect.irregular 'os', 'oses'
end

For simplicity and clarity, I chose the irregular form since I didn’t figure on needing to match regular expressions against more complex model names.

Since there are many articles dedicated to the model side of things where relationships are concerned, I will skimp on discussing model implementations. Please see many-to-many-dance-off by Josh Susser or the has_and_belongs_to_many page on the Ruby on Rails wiki site for a couple of classics on the topic.

The models are straightforward, as shown below. Note that the browsers_oses table does not get its own model. Rails simply expects the table to be a concatenation of the two models pluralized and the model names in alphabetical order.

class Os < ActiveRecord::Base
  has_and_belongs_to_many :browsers
end

class Browser < ActiveRecord::Base
  has_and_belongs_to_many :oses
end

I’m not a big fan of the default views the rails scaffolding produces, but I do tend to run script/generate scaffold “model_name” to get the ball rolling quickly, anyway. So fire up a couple of views with:

script/generate scaffold browser
script/generate scaffold os

Note: I removed all previously generated files and regenerated the Os model and views after adding the irregular plural inflection rule described above.

Once I get my models and views, the first thing I do is create a form partial for each:

app/views/oses/_form.html.erb

	
OS
	<p>
		Vendor
		<%= text_field :os, :vendor, :value => @os.vendor %>
	</p>

	<p>
		Name
		<%= text_field :os, :name, :value => @os.name %>
	</p>

	<p>
		Version
		<%= text_field :os, :version, :value => @os.version %>
	</p>

	<p>
		Short Name
		<%= text_field :os, :short_name, :value => @os.short_name %>
	</p>

There’s nothing fancy about the Os form as there’s no references to select drop-downs or the likes. With the above wrapped in a fieldset with legend of Os. I then tweak app/views/oses/edit.html.erb like so:

Editing OS

<% form_for(@os) do |f| %>
  	<%= f.error_messages %>
	<%= render :partial => ‘form’ %>

	

    	<%= f.submit "Update" %>
		<%= link_to 'Show', @os %> |
		<%= link_to 'Back', oses_path %>
  	
<% end %>

And similarly for app/views/oses/new.html.erb:

New OS

<% form_for(@os) do |f| %>
  	<%= f.error_messages %>
	<%= render :partial => ‘form’ %>

  	

    	<%= f.submit "Create" %>
		<%= link_to 'Back', oses_path %>
  	
<% end %>

app/views/oses/show.html.erb is nearly a cut-n-paste of the _form.html.erb file with the input tags stripped out:

	
OS
	<p>
		Vendor
		<%= @os.vendor %>
	</p>

	<p>
		Name
		<%= @os.name %>
	</p>

	<p>
		Version
		<%= @os.version %>
	</p>

	<p>
		Short Name
		<%= @os.short_name %>
	</p>



	<%= link_to 'Edit', edit_os_path(@os) %> |
	<%= link_to 'Back', oses_path %>

It would be nice if the tag fields were action aware and intelligently generated inputs or text rendering according to whether new, edit, or show was the action, wouldn’t it??

The OsesController model is unchanged from the generated scaffolding code, so I won’t list its code here. Lets hop over to Browsers model and view as this is the model I do the most interesting things with. I will be rendering the Browser inputs so that one of the input is a checkbox list of all available OSes. To do this, I am effectively performing a “find all” on the Os model, so I DRY my code by adding the following method to the BrowsersController:

  def get_all_oses
    @oses = Os.find(:all, :order => 'vendor, version')
  end

Declaring small, single purpose methods is a good practice to be in the habit of. As it happened, I decided at some point to order the checklist by vendor and version. Instead of having to change code in four or five methods, I only had to update the one get_all_oses method. A tad bit of extra work up front pays off!

Similarly, compound names get their own method in the model class so I have ability to easily change without hunting down references everywhere in the view. So the Os model presented above becomes:

class Os < ActiveRecord::Base
  has_and_belongs_to_many :browsers

  def display_name
    "#{vendor} #{name} #{version}"
  end
end

And then I reference like so in the Browser view’s form partial:

	
Browser
	<p>
		Name
		<%= text_field :browser, :name, :value => @browser.name %>
	</p>

	<p>
		Version
		<%= text_field :browser, :version, :value => @browser.version %>
	</p>

	<p>
		Operating Systems
		<% @oses.each do |os| %>
			<%= check_box_tag(
                            "browser[os_list][#{os.id}]",
                            "1",
                            @browser.oses.detect{|d| d == os}) %>
			<%= "#{os.display_name}"%>
		<% end %>
	</p>

	<p>
		Short Name
		<%= text_field :browser, :short_name, :value => @browser.short_name %>
	</p>

A few important things to note here about the Operating Systems checklist:

• the @oses variable is a list of all Oses as per the get_all_oses method.
• I gave the checkbox name “browser[os_list][#{os.id}]” which causes the params to collect all checkboxes into an “os_list” hash that is contained in the browser keyword on the params hash. Keep this in mind because we’re going to leverage this in a moment.
• I don’t do anything with the values of the checkbox, so the value assigned (”1″ in this case) is of little concern.
• The @browsers.oses.detect{|d| d == os} line activates the checkbox if the browser already has the Os associated with it. (quite important for edit actions).

So the Operating Systems checklist is simply an iteration over all OSes, emitting a checkbox input control for each and setting the checked flag accordingly. So how do we handle this in the controller? We don’t! That’s right. Not in the controller, but in the model. This is “The Rails Way” as described in the Skinny Controller, Fat Model approaches championed by Jamis Buck and The Rails Way crew. My approach is to add a attribute accessor called “os_list” to the Browser model and a callback to the after_save event. So the Browser model now becomes:

class Browser < ActiveRecord::Base
  has_and_belongs_to_many :oses

  attr_accessor :os_list
  after_save :update_oses

  private 

  def update_oses
    oses.delete_all
    selected_oses = os_list.nil? ? [] : os_list.keys.collect{|id| Os.find_by_id(id)}
    selected_oses.each {|os| self.oses << os}
  end
end

So there’s a bit of magic! The update_attributes and save methods will assign the os_list hash from the params to our accessor “os_list” property automatically and thus provide us convenient access to the hash data in our callback handler. This is Rails at its best. Paul Barry gets the credit for being the first to put it together (at least for me).

What this method does is first clear out all the currently associated Oses. Then, if there are no selected Oses (in which case, items will be []), nothing happens with the loop, otherwise, each item is pushed onto the browser.oses list. When I first started writing Ruby on Rails apps, I was a stickler for not hitting the database unnecessarily and I would write lots of conditionals to avoid doing so.

However, the number of bugs I found in such logic eventually led me down the path of aggressively reducing lines of code in situations where it simply does not matter. Here, we’re talking about, at most, about 10 operating systems defined in the app I’m writing and I am very infrequently going to be adding new browsers to the list (about as often as a major version comes out as a rule of thumb). Is it really worth the extra code and the extra specs (you are writing test cases, aren’t you?) to gain so little? Rails is smart. It’ll issue a delete statement only if there are actually Oses in the list and it’ll only issue one DELETE statement, too! Check this session history out (for PostgreSQL):

  SQL (0.000153)   BEGIN
  SQL (0.000337)   DELETE FROM "browsers_oses" WHERE browser_id = 14 AND os_id IN (8,9)
  SQL (0.009701)   COMMIT
  SQL (0.000131)   BEGIN
  SQL (0.000194)   INSERT INTO "browsers_oses" ("browser_id", "updated_at", "os_id", "created_at") VALUES (14, '2008-10-24 19:33:43.107494', 8, '2008-10-24 19:33:43.107494')
  SQL (0.000649)   COMMIT
  SQL (0.000094)   BEGIN
  SQL (0.000191)   INSERT INTO "browsers_oses" ("browser_id", "updated_at", "os_id", "created_at") VALUES (14, '2008-10-24 19:34:01.088552', 9, '2008-10-24 19:34:01.088552')
  SQL (0.000570)   COMMIT
  SQL (0.000086)   BEGIN
  SQL (0.000199)   INSERT INTO "browsers_oses" ("browser_id", "updated_at", "os_id", "created_at") VALUES (14, '2008-10-23 20:24:59.809242', 2, '2008-10-23 20:24:59.809242')
  SQL (0.000657)   COMMIT
  SQL (0.000076)   BEGIN
  SQL (0.000110)   COMMIT
Redirected to http://localhost:3000/browsers/14
Completed in 0.08188 (12 reqs/sec) | DB: 0.01585 (19%) | 302 Found [http://localhost/browsers/14]

Now, if you’ve got a situation where 100’s of users are performing a similar action and the small doses truly add up to something significant in your daily logs, then definitely optimize. Just be cognizant of your use-case and profile your application for performance before getting fancy with the conditional updates, otherwise you’re in the trap of premature optimization and not getting something else done you might have wish you were!

Ok, having digressed a bit, lets get back on course. So what does the Browser Controller now look like? Well, the only thing I have to add is a call to “get_all_oses” just in case of a failure to save and the redirect back to the same page occurs. So this is what we have:

   def get_all_oses
     @oses = Os.find(:all, :order => 'vendor, version')
   end  

  # POST /browsers
  # POST /browsers.xml
  def create
    @browser = Browser.new(params[:browser])
    get_all_oses

    respond_to do |format|
      if @browser.save
        flash[:notice] = ‘Browser was successfully created.’
        format.html { redirect_to(@browser) }
        format.xml  { render :xml => @browser, :status => :created, :location => @browser }
      else
        format.html { render :action => “new” }
        format.xml  { render :xml => @browser.errors, :status => :unprocessable_entity }
      end
    end
  end

  # PUT /browsers/1
  # PUT /browsers/1.xml
  def update
    params[:oses] ||= {}
    @browser = Browser.find(params[:id])
    get_all_oses

    respond_to do |format|
      if @browser.update_attributes(params[:browser])
        flash[:notice] = ‘Browser was successfully updated.’
        format.html { redirect_to(@browser) }
        format.xml  { head :ok }
      else
        format.html { render :action => “edit” }
        format.xml  { render :xml => @browser.errors, :status => :unprocessable_entity }
      end
    end
  end

One last trick for the eagle eyes: The form image I posted positions the labels in bold above the inputs and with a trailing colon, but nary a <BR> element (or colons) to be seen in the views. I accomplished this with simple CSS styling by switching the label element to a block element (rather than inline as is the default) and then providing the colon as additional content:

label {
	display: block;
	font-weight: bold;
}
label:after {
	content: ':';
}

So there you have it. Leveraging the Rails framework appropriately, you can easily provide a checklist generated from one model on another’s edit form and have those records maintained in a many-to-many relationship without bloating your views or controllers.

To get started, I needed to know how to get the data into Trac. The following links gave me an API I could utilize to create trac pages and content:

Trac Data Models
The Data model Python code

Great! Except there’s one small problem. I don’t really know python all that well, even though I did do a bit of Zope development, oh, five years ago. These days, my language of choice is Ruby, so I needed to figure out how to parse the Oddmuse syntax and turn it into Trac syntax. The strategy: Parse with Ruby, load cleaned page files with Python.

This script will take a filename at command line and convert it and save back to file, but different extension (I chose *.om for “oddmuse”). In the script below, I made the command-line optional as I discovered I didn’t handle every case as I worked on developing this script, so I simply changed the line that pulls the command-line argument to point to a specific file and output such to terminal and this allowed me to debug and fix as I went:

#!/opt/local/bin/ruby
# $FS  = "\xb3";      # The FS character is the RECORD SEPARATOR control char in ASCII
# $FS0 = "\xb3";      # The old FS character is a superscript "3" in Latin-1
# $FS1 = $FS . '1';   # The FS values are used to separate fields
# $FS2 = $FS . '2';   # in stored hashtables and other data structures.
# $FS3 = $FS . '3';   # The FS character is not allowed in user data.

FS = 179.chr

SITE_NAME = "corporate_wiki"
ATTACHMENT_URL_BASE = "https://intranet.example.com/#{SITE_NAME}/attachment/wiki/ConvertedAttachments/"

require 'find'
require 'ftools'

def safe_page_name(pagename)
  result = pagename.gsub("'","")
  result = result.slice(/(\w+)/).first
end

def get_section(page, section)
  page.each_with_index {|e,i| return page[i+1] if e == section}
  return ”
end

def asterick_prefixed(text)
  t = text.match(/(\*+)([^\b]*)/)
  return text if t.nil?

  tokens = t.to_a
  return (’  ‘ * tokens[1].size) + ‘* ‘ + tokens[2]
end

def colon_prefixed(text)
  return ”  #{colon_prefixed(text.slice(1,text.size))}” if text[0] == “:”[0]
  return text
end

def pound_prefixed(text)
  return ”  1. #{text.slice(1,text.size)}” if text[0] == “#”[0]
  return text
end

def fix_headers(text)
  t = text.match(/(=+)([^=]+)(=+)/)
  return text if t.nil?

  tokens = t.to_a
  return “#{tokens[1]} #{tokens[2].strip} #{tokens[1]}”
end

def replace_a_url(url, text)
  text.gsub!(”http://#{url}”, ATTACHMENT_URL_BASE)
  text.gsub!(”https://#{url}”, ATTACHMENT_URL_BASE)
  text.gsub!(”http:/#{url}”, ATTACHMENT_URL_BASE)
  text.gsub!(”https:/#{url}”, ATTACHMENT_URL_BASE)
  return text
end

def replace_wiki_urls(text)
  matches = text.match(/\[http(.)*\]/)
  result = text
  if matches
    result = replace_a_url(”wiki.example.com/#{SITE_NAME}/wikifiles/”, result)
    result = replace_a_url(”pdfreviewfiles/”, result)
    result = replace_a_url(”cgi-bin/”, result)
  end
  result
end

def convert_formats(text)
  result = text.gsub(/\[\[(\w+)\]\]/,”[wiki:" + '\1' + "]“)
  result = asterick_prefixed(result)
  result = colon_prefixed(result)
  result = pound_prefixed(result)
  result = replace_wiki_urls(result)
  result = fix_headers(result)
  result
end

def oddmuse_to_trac(text)
  result = ”
  in_pre = false
  text.split(”\n”).each do |line|

    # Detect indented lines as these are rendered as PRE html blocks
    trimmed = line.lstrip
    is_prefixed = ((trimmed.size < line.size) and (trimmed[0] != '*'[0]))
    result << "{{{\n" if (is_prefixed and !in_pre)

    result << "}}}\n" if (!is_prefixed and in_pre)
    in_pre = is_prefixed

    # Don't process special characters when in PRE block
    if in_pre
      result << line << "\n"
    else
      result << convert_formats(line) << "\n"
    end
  end
  result += "}}}\n" if in_pre
  result
end

path = ARGV[0] || "page/U/UsingThePhones.db"
raw_page = File.new(path).read
page2 = raw_page.split(FS + '2')
page3 = raw_page.split(FS + '3')

text = get_section(page3, 'text')

pagename = File.basename(path).split('.').first
author = get_section(page2, 'username')
address = get_section(page2, 'ip')
body = oddmuse_to_trac(text)

puts "writing: #{pagename}.om"
outfile = File.new(path.gsub('.db','.om'),'w')
outfile.puts 'pagename:' + pagename
outfile.puts 'author:' + author
outfile.puts 'address:' + address
outfile.puts body
outfile.close

puts body if ARGV[0].nil?

Below, comes the Python side of the equation. Once I did the heavy lifting in Ruby, I needed to generate all the pages. As you can see, there’s some parsing happening, but its very simple parsing and I was able to apply what simple Python knowledge I still retained pretty effectively:

import sys
from trac.env import Environment
from trac.wiki.model import WikiPage

print sys.argv[1]
file = open(sys.argv[1], ‘r’)
pagename = file.readline().split(’:')[1].split(’\n’)[0]
author_name = file.readline().split(’:')[1].split(’\n’)[0]
address = file.readline().split(’:')[1].split(’\n’)[0]

text = file.read()

env = Environment(’/srv/www/trac/corporate_wiki’)

# Read an existing or new WikiPage:
page = WikiPage(env, pagename)
if page.text != text:
        page.text = text
        page.save(author=author_name, comment=’imported from oddmuse wiki’, remote_addr=address)

As you can see, this file simply takes the command line argument, open the file for reading, pull the various variables out with the remainder of the file going to the page content.

During the conversion, I noticed some pages were failing to convert at all, like “Michael’sTodoList” The culprit, the tick in the page name and thus the filename. The scripts themselves weren’t the problem, it was the xargs parameter passing that was the issue (getting to that below). So I ran the below script to rename all the troublesome filenames and then added similar tick to underscore substitution in the main Ruby script above.

require 'find'
require 'ftools'

total_size = 0

Find.find('./page') do |path|
  if FileTest.directory?(path)
    if File.basename(path)[0] == ?.
      Find.prune       # Don’t look any further into this directory.
    else
      next
    end
  else
    if path.match(/[\']/)
      safe_path = path.gsub(”‘”, “_”)
      puts path + ‘ to ‘ + safe_path
      File.move(path, safe_path)
    end
    end
  end

A simple up-front execution of the script was all that was needed to now be able to pick up the missing pages:

ruby fix_unsafe_files.rb

Finally, to bring it all together, I utilized find to locate all the *.db Oddmuse files which I had located into the various wiki subfolders where these scripts sat, passing the filename to the script via the xargs utility:

find . -name *.db -print0 | xargs -0 -L 1 ruby rdpage.rb

I then essentially repeated the above, but for the generated *.om files, passing to the Python mkpage.py script:

find . -name *.om -print0 | xargs -0 -L 1 python mkpage.py

One last thing, before we’re done. Each wiki had attachments. So I had to think how to get those attachments referenced and linked to the Trac wiki. A little investigation revealed that each attachment got a database entry in the attachment table. My task was a bit complicated by the fact that the users over the years in the Oddmuse environment scattered their attachments everywhere and also used varying syntax to refer to them, hence, if you review the main Ruby parsing script, you’ll see the “replace_a_url” method above that cleans all those funky URLs up. So the script I used below simply scans through all the directories where we had files stored and attached them to one “ConvertedAttachments” page. Probably not the ideal solution, but again, got the job done quickly.

#  type |          id          |  filename  |  size  |    time    | description | author |      ipnr
# ------+----------------------+------------+--------+------------+-------------+--------+----------------
#  wiki | ConvertedAttachments | gotapi.png | 200272 | 1218381947 |             | michael | 192.168.16.100

path = ARGV[0] || ‘generate_attachments.rb’
filename = File.basename(path)

puts “insert into attachment values (’wiki’, ‘ConvertedAttachments’, ‘#{filename}’, #{FileTest.size(path)}, null, null, ‘oddmuse’,'192.168.1.246′);”

So, running the above needs to be piped to a SQL fisle and then executed against your Trac database. In my case, Postgresql. Since I had many directories to snatch up, I ran it for each folder as appropriate and simply kept appending until I had all the attachment directories represented.

ls | xargs -0 -L 1 >> attachments.sql
psql trac_db < attachments.sql

All in all, not too bad of a conversion for a few hour’s work. Its about 95% correct. Some of the page names didn’t translate to Trac, and could probably do with some regexp search and replace on the page names themselves. The biggest gain is that we have preserved the information in the old systems by porting it to the new systems we all know and use on a daily basis, so WikiGardening is more likely to keep the content fresher and its one less system for our end-users to figure out how to use.

I can now retire the server running Oddmuse, stop doing backups and keeping up with documentation and training new system administrators on how to manage Oddmuse AND Trac.

I am using Mac OS X Leopard 10.5.4 at the time of this writing. These are the steps I took to fix that most hideous of all colors, dark blue on black background:

1. Set your terminal theme colors to your liking
2. Set up ls to colorize directory listings by default. There are two ways to do this: Either set the CLICOLOR Environment variable or add an alias for ls to include the -G flag. I chose the CLICOLOR flag:

   export CLICOLOR=1
   

3. Next up, install the ANSI color SIMBL plugin found here: http://niw.at: works of Yoshimasa Niwa. Make sure Terminal.app is closed while you install the plugin then relaunch Terminal to find under its main menu, “Color Preferences…”
4. Finally, edit that dark blue away!

If you’re interested in tailoring the output of the colors even further, you can also export the LSCOLORS variable:

export LSCOLORS="exfxcxdxbxegedabagacad"

And then change according to the manual entry for ls (”man ls”):

One final trick to get my bash shell exactly like I like it was to set the prompt. This can likewise be done by editing ~/.profile:

PS1="[\u@\h \W] ”

I combed the documentation for days trying to figure out exactly how to set up a server to hand out time to all my other servers. Normally, my Google-fu can pierce just about any need, but “time” “server” “local” and so on are all too common terms in both client-and-server and client-only configurations and by far and away, the bulk of the documentation guides you through the latter. The documentation that guides you through the former is dense with references to peers, stratum, broadcasting, multi-casting, and so on.

So, here’s how to set up an NTP service as both client and local time server on CentOS 4:

yum install ntp

Then edit the /etc/ntp.conf file and set up the public ntp server pools and uncomment the broadcast line and change IP mask to match your network’s:

server 0.rhel.pool.ntp.org
server 1.rhel.pool.ntp.org
server 2.rhel.pool.ntp.org
broadcast 192.168.1.255

Modify your /etc/sysconfig/iptables to allow other servers to connect:

-A RH-Firewall-1-INPUT -p udp -m udp --dport 123 -j ACCEPT

Finally, go to the “client server” and install ntp on it just as you did with the ntp server, except, this time, you edit your /etc/ntp.conf file to point to your new local time server. In my case, I set up two servers to give out times and I added ntp.1 and ntp.2 to my local DNS servers, so my config file for the “client servers” uses:

server ntp.1.example.com
server ntp.2.example.com

Its really that simple! Its probably not the most secure way to do the job as there’s plenty of information overload in the ntp documentation on configuring securely. However, with all of my servers sitting in a trusted VLAN and the DNS entries are only served to these servers and NTP port is blocked between this VLAN and others, I reckon it would be fairly hard to hijack the local ntp services. In other words, the simple approach is good enough, for now.

Today, we have Pradipta’s Rolodex!
digg link Reddit.

To all developers out there unfortunate enough to get caught in this web, thanks, for you have made me laugh out loud harder than I have in a good while!

Cheerios!

A bit of hunting around turned up this list of zip code databases. The first link to CivicSpace database appears to be defunct (I got a Go Daddy “this page is parked” page). So, the next free one, offered by Popular Data turned out to be exactly what I was looking for. It may be a “little old” as the review site says, but its good enough for me to get started with associating my data with geocoded locations and explore the wonderful world of mapping offered by Google’s Maps API.

To load it up in MySQL and PostgreSQL, I used the following Ruby script to generate a bunch of insert statements:

require 'rubygems'
require 'fastercsv'
source_file = 'ZIP_CODES.txt'
outfile = File.new('us_zip_codes.sql','w')

# generate the truncate statement if we want to empty the table
outfile.puts "truncate us_zip_codes;"

# generate the SQL Insert statements
FasterCSV.foreach(source_file, :headers => false) do |cols|
  row = "INSERT INTO us_zip_codes VALUES ("
  row << as_string(cols[0]) << ","
  row << as_number(cols[1]) << ","
  row << as_number(cols[2]) << ","
  row << as_string(cols[3]) << ","
  row << as_string(cols[4]) << ","
  row << as_string(cols[5]) << ","
  row << as_string(cols[6]) << ");"
  outfile.puts row
end
outfile.close
puts "copied #{i} records."

Create the zip code table with the following SQL:

create table us_zip_codes (
  zip_code char(5),
  latitude float(10,6),
  longitude float(10,6),
  city varchar(255),
  state char(2),
  county varchar(255),
  zip_class varchar(255)
);

And finally, with the table in place and the SQL insert statements generated, I loaded the data into MySQL with the following from command line:

mysql target_db_name < us_zip_codes.sql

The problem: I wanted to introduce a property editor metaphor for the website I’m working on where properties could expose edit forms for just about any situation, much like wordpress’ widget interface does.

That is, there’s an area of the current page that shows basic information about the property in a read-only (and preferably compact) form, and user could click an “edit” button and exposed an editable version of the properties. The “edit” link becomes a “cancel” link, which, when clicked, simply discards the edit form and return the initial compact view state.

The problem is, Rails doesn’t really have any good helpers for reusing a design concept in your views. I found that even with partials, the code was really starting to bog down and become both unmaintainable and unreadable. I needed a simple mechanism to construct my property editors. I started out with helper methods. But that wasn’t much better as the code just started ending as ruby here-docs and became a maintenance issue of another sort! Take a look at this embarrassment:

result = "<table><tr>"
result += "<th colspan=2>"
result += button_image_action('Group selected together', 'link.png')
result += button_image_action('Copy selected to this group', 'link_add.png')
result += button_image_action('Move selected to this group', 'link_go.png')
result += button_image_action('copy group', 'page_copy.png')
result += button_image_action('cut group', 'cut.png')
result += button_image_action('paste group', 'page_paste.png')
result += button_image_action('delete group', 'delete.png')
result += "</th></tr>"
result += "</table>"

Ok, I admit it, I chopped out more than half again as many lines as you’re looking at there, and perhaps worse, this isn’t actually the original HTML code that led me down this path, but lets take a look at this approach anyway, as I learned something valuable in the process and it was my first attempt at DRYing my views. First thing, first, get the above HTML back into the erb file:

			<%= button_image_action('Group selected together', 'link.png') %>
			<%= button_image_action('Copy selected to this group', 'link_add.png') %>
			<%= button_image_action('Move selected to this group', 'link_go.png') %>
			<%= button_image_action('copy group', 'page_copy.png') %>
			<%= button_image_action('cut group', 'cut.png') %>
			<%= button_image_action('paste group', 'page_paste.png') %>
			<%= button_image_action('delete group', 'delete.png') %>
		

Which promptly let me to trying something like this:

def button_image_action(title, image_filename, button_text = '', url = '')
    form_for @cube url do |f|
  	  <<-TEXT
  	    #{button_text}
  	    
  	    
  	  TEXT
     end
  end

I thought it was shaping up nicely, but I got completely blindsided when it came to rendering this bit. You see, the Rails Form Helpers are unavailable in a regular helper! They require ERB (being inside <% %> and <%= %>) to actually properly render their blocks.

I fiddled around for a bit to try to jump this hurdle, but it just simply ain’t gonna work without some serious hacking. I’m happy to report that I got a little wiser and stepped back from the problem and reevaluated my approach in general. I realized, I wasn’t getting away from doing HTML code in helpers! Bottom line: Helpers are great, but you’re doing something clearly against “The Rails Way” when you start rendering large chunks of HTML code from helpers. It just isn’t a great approach and if you have designers on your team, they can get quite lost hunting around for all those HTML snippets.

So, how could I get all of my HTML back into *.erb files where they belonged, yet develop some helpers that would make mincemeat of the coding effort to build these fancy toolbars and forms I had coming? Fellow colleague, Steven Beales said, “you need to use Ruby blocks.” To which, my first reaction was, “what are Ruby blocks?” To my great benefit, he explained by pointing me straight at Block Helpers and DRY Views in Rails.

Truth be told, I mostly understood this article, but not entirely. Even so, I dutifully set off to solve my problem with this approach. This led me to a bit of copying and pasting (and crediting)…

  # From:  http://errtheblog.com/posts/11-block-to-partial
  #
  # captures the output of our passed block using Rails’ capture method and adds
  # it to our options hash under the key of :body. Next it renders our passed
  # partial, sending in our options hash as :locals
  def block_to_partial(partial_name, options = {}, &block)
    options.merge!(:body => capture(&block))
    concat(render(:partial => partial_name, :locals => options), block.binding)
  end

Look at that carefully and, if I may be so bold to suggest, go read up on ERR the Blog to better understand as this method is key and I daresay was appropriately called “tomfoolery” by the wise authors therein. This bit of code really forced me to finally begin to learn and understand what the heck block passing was all about. In a nutshell, this little gem lets you pass options that become local variables to the partial and the block is the contents to be rendered within the partial when you yield to the passed block.

  # Calls given partial, injecting the options hash into the partial's local hash
  def variables_to_partial(partial_name, options = {})
    render(:partial => partial_name, :locals => options)
  end

The block_to_partial is a great start, but I wanted to simplify my calls and also enforce a bit of use-pattern on the developer (i.e. me) so that all property editors had essentially the same behavior pattern (and components). Thus, we introduce the property editor container which in turn can have one or more sections associated with it:

  # Generates a division around the given block that is styled with "property-editor"
  # Property editors are intended as a view on data that has both a condensed display and
  # an expanded display that lets you edit the information contained in the property editor.
  def property_editor(id, title, options = {}, &block)
    @id = id
    block_to_partial 'layouts/property_editor', options.merge(:id => id, :title => title), &block
  end

  # Renders content of a section (provided by block) inside a property editor division
  # The stylesheet contains styling for the following section_id's:
  #   => "show" - the section initially visible
  #   => "edit" - the section made visible when the edit button is clicked
  def property_editor_section(section_id, options = {}, &block)
    block_to_partial('layouts/property_editor_section',
      options.merge(:section_class => "property-editor-#{section_id}",
        :section_id => "#{@id}-#{section_id}"),
        &block)
  end

The property editor partial:

<div <%= %[id="#{id}"] %> class=”property-editor”>
	<div class=”property-editor-title”>
		<div style=”float:right”>
			<a href=”javascript: void(0)” onclick=”toggle_div(’<%= id %>-show’);toggle_div(’<%= id %>-edit’);”>edit</a>
		</div>
  		<%= title %>
	</div>
	<%= body %>
</div>

and the property editor sections are rendered with this partial:

<div <%= %[id="#{section_id}"] %> <%= %[class="#{section_class}"] %> <%= %[style="display:none"] if section_id =~ /(.+)?\-edit/  %>>
	<%= body %>
</div>

With these helpers and partials, property editors as a concept is very easy to pull together in my view files. As you can see, if my section is an “edit” section, its hidden at the outset. The button to toggle between show and edit is in the property editor partial itself in which an onclick javascript calls toggle_div to make this happen. The Javascript is very straightforward:

function toggle_div(div_name) {
	var div = $(div_name);
	div.getStyle('display') == 'none' ? div.setStyle('display', 'block') :	div.setStyle('display', 'none');
}

Here’s just one such property editor operating on my “cube model”:

<% property_editor 'properties', 'Properties' do %>
	<% property_editor_section 'show' do %>
		<%= @cube.name %><br/>
		<%= render :partial => '/cubes/cube_stats' %>
	<% end %>

	<% property_editor_section 'edit' do %>
		<%= render :partial => 'form' %>
	<% end %>
<% end %>

What’s more, I had a complete set of CSS selectors with which I could control my property editor and its associated sections:

.property-editor {
	margin-top: 5px;
	border: 3px solid #FDEFE6;
}

.property-editor-title {
	padding: 2px;
	padding-left: 5px;
	padding-right: 5px;
	background-color: #EEE;
	color: #2F6569;
}

.property-editor-show, .property-editor-edit {
	padding: 5px;
}

.property-editor p {
	margin: 0px;
	padding: 0px;
}

Well, all in all, that’s a good bit of rambling, but I hope others can benefit from my experiences with Ruby, blocks, partials, and DRY up those views.

My needs were simple. I wanted to use AJAX to pop up an embedded dialog (just some fancy CSS styling to get a DIV hovering over an overlay, really), update some values, and have that info populate back to the table where said information was presently displayed. I also wanted to be able to add new records and delete existing rows through AJAX calls rather than refreshing the whole page.

This article will walk you through the basic approach I used. I’ll leave out the fancy dialogs and all that and just hard-code some buttons so as to keep this article tightly focused on the task at hand: manipulating tables consistently across all browsers through Mootools 1.2.

This technique was borne of some code and help I got from Jan Kassens http://blog.kassens.net/ on the IRC channel for mootools (#mootools at freenode.net).

First, the HTML page:

<table id="mytable" style="border: 1px solid blue">
    <tbody id="mytbody">
    <tr id="row1">
        <td>r1c1</td>
        <td>r1c2</td>
        <td>r1c3</td>
    </tr>
    <tr id="row2">
        <td>r2c1</td>
        <td>r2c2</td>
        <td>r2c3</td>
    </tr>
    <tr id="row3">
        <td>r3c1</td>
        <td>r3c2</td>
        <td>r3c3</td>
    </tr>
    <tr id="row4">
        <td>r4c1</td>
        <td>r4c2</td>
        <td>r4c3</td>
    </tr>
    </tbody>
</table>

Cut and paste that into a more complete HTML document if you’re gonna play with it. But as you can probably see, that code generates a fairly simple table with named table row elements and a named tbody element (which is very important for IE).

One of the first things I found out is that you can’t inject directly on the table element in IE, you have to inject into the TBODY element, otherwise, IE just accepts your injects gleefully without ever presenting them (I know this because I could subsequently select with $(’new_element’) and delete the elements I dynamically created!).

So now that we have that first big “gotcha” out of the way, lets look at some mootools functions you can use to mess with your tables. First, be sure you have mootools loading into your HTML document:

<script type="text/javascript" src="scripts/mootools-1.2-core-nc.js" charset="utf-8"></script>

And now, some javascript to let us do a little table manipulation:

<script type="text/javascript">

	function htmlToElements(str){
		return new Element('div', {html: '<table><tbody>' + str + '</tbody></table>'}).getElement('tr');
	}

	function add_row() {
		var myTBody = $('mytbody');

		newRow = htmlToElements("<tr><td>foo</td><td>bar</td></tr>");
		newRow.inject(myTBody);
	}
	function delete_row() {
		$('row5').dispose();
	}

	function replace_row(row) {
		var newRow = htmlToElements('<tr id="' + row + '"><td>foo</td><td>bar</td><td>replaces!</td></tr>');
		newRow.replaces($(row));
	}
</script>

With this, I can put some buttons on the page to click and call these nifty functions accordingly:

<button onclick="add_row();">add row</button>
<button onclick="delete_row();">delete row</button>
<button onclick="replace_row('row2');">replace row 2</button>

So, lets go over this a bit. delete_row() is the simplest one. It just shows that you can use mootool’s dollar function to grab a TR and throw it away. Works great in FF2 and IE without any tricks. Next up, add_row(). This one turned out to be tricky because I was initially trying to add to the “mytable” TABLE element and it worked in Firefox, but not Internet Explorer. I really got frustrated with this one, trying all manner of innerHTML, outerHTML, DOM manipulators (e.g. appendChild) with *no* success until Jan tipped me off that its the tbody you have to work against.

Alright, so with that nasty one out of the way, the next step was getting rows into IE. It seems that just assigning innerHTML property for a TR was a major no-no and there’s plenty of blogs and other forum posts to tell you all about this one. But I get my new data from the server as HTML, not DOM objects. I needed a simple helper method to get me to DOM elements I could inject. So Jan whips up what I needed in htmlToElements(str) function in which a a fully valid table is constructed (including the TBODY element IE depends on) in which the TR is selected and returned from it. With a TR element in hand, it was embarrassingly simple to call mootool’s inject on the TBODY element.

But wait, there’s a bonus round: You can also replace an existing TR just as easily as you can add a new TR to the table and Internet Explorer (or maybe it was mootools!) tickled me pink in happily complying with my wishes. With this toolset, you can build a fairly comprehensive set of functionality to add, delete, and update your rows in any browser.