Serving HTML tables as Excel

Posted by unixmonkey on September 22, 2010

Did you know that Excel can open a plain-old HTML table file and treat it just like a native Microsoft XLS file?

I’ve been doing this for ages, and its quite simple to pull off; just name your file something.xls and send the html with the content-type of “application/” (and even that is not strictly required).

Even functions are somewhat supported like so.


However, there are a few drawbacks to this worth sharing when trying to style the tables with CSS.

1) Multiple class names are not supported:

<style type='text/css'> { background-color: red; }
<td class='foo bar'></td>

Will not apply the background color. You have to use only a single class per element like so:

<style type='text/css'> { background-color: red; }
<td class='foo'></td>

2) Descendant selectors are not supported:

<style type='text/css'>
  tr.odd td { background-color: red; }
<tr class='odd'>

Will not apply the background color either. You will have to be very specific about the element you want to style.

3) Certain colors and properties don't work:
If you use a color like #ECECEC (a light gray), it will come out white, If you use #CCCCCC (a darker gray) it will work. Stick to the basics like #000000 (black) if you can.

4) You'll have to add your styles either inline or in an html <style> block.
This shouldn't come as a surprise, but linking to an external stylesheet won't work. Excel won't reach out to your server to style the content.

5) Granularity will not be easily achieved:
Styling something with a 1px border is going to translate into a .5pt border. That's just how Excel rolls I guess.

Try marking up an Excel workbook and using 'save as' -> 'html' and opening up the file to checkout the markup Excel uses. This can give you some clues to what is acceptable.

I hope these simple tips help someone in a similar situation, and keep them from using a heavy arcane library to generate excel files with some added styling.

Getting attachment_fu to play nice with acts_as_versioned

Posted by unixmonkey on February 09, 2008

If you’ve ever wanted to keep track of revisions to document files or images in your Rails app, you are likely to want to use Acts_as_versioned, which is the authority on versioning database records, and Attachment_fu, which is the authority on uploading files with Rails.

The problem is that they don’t know about each other and will step on each other’s toes without some changes. This article serves as a quick introduction to each, and shows how to make the two plugins get along like best friends.

Acts_as_versioned was written by Rails Core Team member Rick Olsen (who also wrote attachment_fu and Restful_authentication among others) that essentially makes a mirror table of the one you want to version, and keeps every version of the record you are updating.

Say I have a document table with fields like this:

id title description
1 rep08 2008 report

Acts_as_versioned will add a column “version”, and a separate table “document_versions”.

id title description version
1 rep08 2008 report 1

The document_versions table will look a bit like this

id document_id title description version
1 1 rep08 2008 report 1

Setting up acts_as_versioned is pretty simple, I got most of my introduction to it from

Now every time you update the original document, the changes are saved in your main documents table, and the version column is incremented by 1.

After a few edits of the document, you’ll see the versioning information in the Document_versions table add up.

id document_id title description version
1 1 rep08 2008 report 1
2 1 rep08 2008 report changed 2
3 1 rep08 chgd 2008 report changed 3

Great! We can now use some of acts_as_versioned’s built-in methods for determining if there are older versions, and be able to view or even revert to them.

Now lets add the ability to upload a file to attach to a document record with attachment_fu.

Attachment_fu is another plugin that makes uploading files and keeping track of them in the database relatively simple.

A good intro to attachment_fu can be found on Mike Clark’s blog

Attachment_fu would require a few changes to our documents table:

id title description version filename content_type size
1 rep08 2008 report 1 rep08.jpg image/jpeg 2854

Don’t forget to add the same fields to your documents_versions table, too.

Once we’ve added the right file fields to the new and edit forms, and image_tag or download link on the show view, we’ve got working file uploads. Nice.

Try to edit a record by attaching a new file, the new file is displayed and the record is preserved as an older version in the versioned table. But if you try to view the old version…wait a minute? Where did my version 1 file go!

That’s right, attachment_fu deletes the old file when you add a new one (as it should if you aren’t versioning your data). Attachment_fu’s rename_file method is the one responsible for deleting (or renaming) the old file when a new one is added, so lets monkeypatch that in our model to not do anything.

def rename_file

Now, it will only overwrite the file if the filename is the same. Lets store each version in its own folder to keep them from clobbering each other by monkey-patching the path files get written to in our model also:

def attachment_path_id
def partitioned_path(*args)
  attachment_path_id + args.to_s

This changes the public path from /0000/0001/rep08.jpg to /1/v1/rep08.jpg

Now, if we want to display the image, we cannot use the ‘public_filename’ method, because it is only given to the Document model, and not the Document_Version model.

That’s okay, because with our new path arrangement, we can reliably predict where the old versions of the files will be kept. You can show them with some code similar to this in your views:

<% for version in @document.versions %>
  Version <%= version.version %>
  <%= image_tag("/documents/#{}/v#{version.version/" + version.filename) %>
  <hr />
<% end %>

Now, when we delete a record, attachment_fu only knows about the current document, and will leave behind orphaned files and folders from the old versions. Lets fix that by having it get rid of the document id folder.

Rails reserves some special methods (callbacks) for performing actions before or after other major actions, lets tap into that by defining a method that will magically get called every time we delete a record.

def after_destroy
  FileUtils.rm_rf(RAILS_ROOT + "/public/documents/#{id}/")

This translates into the shell command rm -rf and deletes our ID directory and everything inside it.


As a wrap up, lets look at our complete Document model:

class Document < ActiveRecord::Base
  has_attachment :storage => :file_system
  def rename_file
  def attachment_path_id
  def partitioned_path(*args)
    attachment_path_id + args.to_s
  def after_destroy
    FileUtils.rm_rf(RAILS_ROOT + "/public/documents/#{id}/") if id

I’ve whipped up a sample Rails app demonstrating the points and code in this article. It uses Rails 2.0.2 with the sqlite3 database.

Download it here: Attachments_versioned (240kb .zip)

I hope this saves some work for someone who wants to leverage these two excellent plugins by Rick Olsen (technoweenie) on the same model without having them fight too much.

Autotest with custom growl notifications in Leopard 5

Posted by unixmonkey on January 17, 2008

Autotest is part of the ZenTest suite for testing ruby and rails apps. Instead of running ‘rake test’ every time you want to run your tests, simply open another tab in your terminal, browse to your rails project directory and run ‘autotest’. It will run your test suite and sit there waiting for any file to be modified. When you edit any file in your rails project, autotest will automatically run your tests again.

To install ZenTest and autotest, open a terminal and run ‘sudo gem install ZenTest’.

This is great, awesome even. I don’t want to understate how useful this is, its like breathing when doing test-driven development, but when I’m coding, I’ll often have a different terminal up front with a script/console shell or tail-ing the development log. I want my tests to get in my face when something goes wrong.

The way to do this is with Growl on OSX, Snarl for Windows, or several other similar pop-up notification apps.

As of this writing, the latest version of Growl is 1.1.2, the ZenTest Gem is 3.8.0, and OSX Leopard is 10.5.1. I installed Leopard as a clean install.

After downloading and installing Growl, while the .dmg is still mounted, open a terminal and run ‘/Volumes/Growl 1.1.2/Extras/growlnotify/’.

This will put a commandline tool called ‘growlnotify’ in your /usr/local/bin dir that is used to pop up those messages. Now you can use a text editor to create a ~/.autotest file.

Lets start simple and check that growl is working with autotest, add this line to your .autotest file:

require ‘autotest/growl’

Then save, and go into your Rails project and run ‘autotest’

If all the pieces were installed right, you should get some nice popups when you run autotest and each time you modify a file in your rails project directory.

Lets pretty this up a bit by over-riding the Autotest::Growl module in our .autotest file. I’ve pretty much copied this verbatim from /Library/Ruby/Gems/1.8/gems/ZenTest-3.8.0/lib/autotest/growl.rb
only I’ve added an image directive to the autotest hooks, a nice red rails logo for test failures, and a green one for test passes, then changed the growl method to substitute my images into the growlnotify command. Be sure the modify the image paths for your images directory.

# ~.autotest
require 'autotest/redgreen'
require 'autotest/growl'
module Autotest::Growl
  def self.growl title, msg, img="/Applications/", pri=0
    title += " in #{Dir.pwd}"
    msg += " at #{"%I:%M %p")}"
    system "growlnotify -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title}"
  Autotest.add_hook :run do  |at|
     growl "autotest running", "Started"
   Autotest.add_hook :red do |at|
     img = "/Users/djones/.autotest_images/rails_fail.png"
     growl "Tests Failed", "#{at.files_to_test.size} tests failed", img, 2
   Autotest.add_hook :green do |at|
     img = "/Users/djones/.autotest_images/rails_ok.png"
     growl "Tests Passed", "Tests passed", img, -2 if at.tainted
   Autotest.add_hook :all_good do |at|
     img = "/Users/djones/.autotest_images/rails_fail.png"
     growl "Tests Passed", "All tests passed", img, -2 if at.tainted

Now create a .autotest_images folder in your home directory and put these images in there (I got them from here), or you can use your own.


Rails exceptions and debug trace even in production mode? 11

Posted by unixmonkey on December 17, 2007

During my recent adventure of setting up a production server for my rails applications, I stumbled upon some strange behavior where if I typed in a non-existent route or caused rails to barf all over itself, it would still show me a debug stack trace instead of the 400.html or 500.html living in /public

I uncommented the ENV[‘RAILS_ENV’] ||= ‘production’ line in /config/environment.rb, and the behavior persisted. I created a controller and view to echo out the environment, and did confirm that the app is running in production mode.

Googling only led to minor success where it was alluded in 1 or 2 posts that rails might think it is still running locally.

I started to eye my Apache mod_proxy_balancer + mongrel_cluster arrangement, where the cluster is set to spawn instances on (localhost). After changing that local address to the outside facing address (192.168.x.x) and accessing it at that address in my vhost conf. Things were working as expected.

Now why would rails act this way? Searching the Rails API led me to the rescue_action and rescue_action_in_public methods, which led me to the local_request? method of determining which of the previous methods get called.

Great, now I’ve found the culprit. The code looks like the below:

# from rescue_action
if consider_all_requests_local || local_request?
def local_request?
  request.remote_addr == LOCALHOST and request.remote_ip == LOCALHOST

An easy fix is to drop a method that overrides this in application.rb

def local_request?
  return false if RAILS_ENV == 'production'

So, if you are having trouble making your app behave like its in production mode, give it a little spanking and remind it not to trust strangers with its debug trace.

Rapid Rails Deployment with Heroku Beta

Posted by unixmonkey on November 21, 2007

Today I got an email from to beta test their rails hosting. Its pretty cool as it provides a web interface to setting up and editing your ruby on rails applications.

Within seconds of my getting the email, I had logged in and created a new rails app. Heroku automatically added a database.yml file pre-populated with the correct database connection info.

I wanted to see if I could get mephisto running quickly, as my host for had gone down last week and shows no sign of returning. I opened their interactive rake terminal and ran db:schema:load and db:bootstrap and my app was instantly available to me to log in and start configuring.

Everything was working fine for several hours while I was setting up to make my first huge post, but them I went to check it out at 6pm, it was down with a 500 error (ngnix), even the main was down with a “zero sized reply”. But I checked again 2 hours or so later, and it was back up.

This is hands-down the easiest deployment I’ve ever seen. Either start with a fresh rails app, or import yours as a gzipped tar file. The only downsides so far:

* There is is a 10mb limit per app, so you can’t freeze rails in your vendor directory.
* There is a bandwidth limit I hit almost immediately after making my app public, and you can’t admin your site at all when overlimit, best you can do is export a dump of your app.
* Your app is always running in development mode. (production and other are planned for later release).

All these are likely just part of growing pains, and will be addressed eventually.

I sent an email to their support staff and my questions were addressed within hours, even late on a Saturday. You can tell its a labor of love.

Sign up for the beta. Its really cool.

Big Nerd Ranch Ruby on Rails Retreat

Posted by unixmonkey on November 19, 2007

After poking around with Ruby on Rails and reading every book and following every tutorial I could get my hands on for over 5 months, I decided to get real and sign up for the Big Nerd Ranch Ruby on Rails course being taught by Charles Brian Quinn, consultant for Highgroove Studios and co-founder of Slingshot Hosting.

I hadn’t previously heard of Big Nerd Ranch, so I was a little worried about the quality of the course, but with the Pragmatic Programmers Rails course being only two days, I felt I needed more time to be completely absorbed in the course material. The Big Nerd Ranch approach to removing you from from all distractions in a quiet, comfortable setting with a very small class size seemed to be just what I needed to focus and regroup.

Continue reading…

Skinning your entire Rails app

Posted by unixmonkey on September 18, 2007

Say I want to deploy my app as a service to several good customers, but I want my app to share the exact layout as each customer site, so it appears to be an internal app to their company and its own clients. I take thier CSS and HTML markup, and make it into a template to wrap around my app’s content.

When I took to task to replicate that functionality in Ruby on Rails, I wasn’t certain would be easily accomplished. All the tutorials I’ve read list template switching as purely CSS affairs. Using CSS to change the presentation of your site is a fine thing, but isn’t enough if you are looking to completely copy the look and feel of a client’s website with your app dropped in.

It took some thought and a little help from the community.

Previously, the system I was used to accepted a site variable passed with the login form that told which template to render. like

That’s ugly and really obvious to what it is doing, but what other way is there to know which template to render?

I recall setting up accounts at a handful of sites that were in the format of:

This is known as using a subdomain as an account key. Luckily, there is a very simple plugin to set that up in Rails

After setting up the plugin, I’m able to access the subdomain name anywhere in the app. Good thing, because I need to access it in application.rhtml (or .haml)

<% # if there's a subdomain, render the partial of the same name -%>
<% if account_subdomain -%>
    <% # first check to make sure account_subdomain is valid and in accounts table  -%>
    <% @account = Account.find_by_username(account_subdomain) -%>
    <% unless @account.nil? -%>
        <%= render :partial => "layouts/"+account_subdomain %>
    <% else -%>
        <% # There's a subdomain, but it isn't valid. Render default template -%>
        <%= render :partial => "layouts/default" %>
    <% end -%>
<% else -%>
    <%= render :partial => "layouts/default" %>
<% end -%>

Notice in the above, that there are no :yield statements. That’s because :yield can live in a partial too. I’ve set up a partial for each subdomain listed in my database in app/views/layouts, and added some logic to render the default layout when a subdomain either isn’t present or is invalid.