Complex views and conventional trickery

This past month, I've been working on a Content Management System (CMS). The CMS is comprised of many sites, each of which have many subwebs (permissioned collections), each site has many pages, each page has many content blocks. The navigation tree of a subweb is a polymorphic relation. So when generating the navigation in the CMS Admin, I use the following method:

module PagesHelper
  # Generate a link to the show page of navigation node
  def link_to_node(node)
    link_to( h(node.display_title), send(*node.route_for_show), :class => node.published? ? 'published' : 'unpublished' ) 
  end
end

In the above example, node the send(*node.route_for_show). I ask the node (which is either a subweb or a page to tell me how to generate the path.

class Page < ActiveRecord::Base
  def route_for_show
    return :page_path, subweb, self
  end
end
class Subweb < ActiveRecord::Base
  def route_for_show
    return :subweb_path, self
  end
end

So the module knows the method to generate its path, but can't actually build the URL. So it passes the information back to the helper, which can generate the path.

I don't know if this is the best way to do it, but its working for me (and I've used this pattern for rendering links for another polymorphic relation).

The ever evolving test suite

I've been working on a rather http://www2.blogger.com/img/gl.link.giflarge rails project and have watched my testing style evolve. And this next step, inspired by Jay Fields has really got me excited. Take a peek.

class Test::Unit::TestCase
  class << self
    def test(*names, &block)
      test_name = :"test_#{names.join('_').gsub(/[^\w ]+/, '').gsub(/ +/, '_')}"
      raise ArgumentError, "#{test_name} is already defined" if self.instance_methods.include?( test_name.to_s )
      if block_given?
        define_method( test_name, &block )
      else
        define_method( test_name) do
          $stderr.puts "Incomplete test '#{names.join(', ')}' @ #{caller.last}"
        end
      end
    end
  end
end

What the above method does is allows for very "fast and loose" test definitions. For example, I can do the following:

class Foo < Test::Unit::TestCase
  # This is a place holder test, and when ran will 
  # print a warning
  test 'this will print a warning when the test runs'

  # This is a genuine test
  test 'this will assert true' do
    assert true
  end
  
  # This is another genuine test, but I'm providing visually 
  # putting the test in another namespace
  test :index => 'should render a list' do
    assert_template 'list'
  end
end

Ultimately, I'm extremely satisfied with how this works. My functional tests can have test definitions with a prefix of the action.

I have updated my Textmate so I can Run Focused Unit Tests, as well as having test highlighted like other keywords (alias, class, require, etc.)

Hpricot, screen_scrape, and horrible pages

I'm an avid Dungeons and Dragons player and have decided I'm going to make a Rails application that will help consolidate the rules for personal use.

So I decided to do a screen scrape http://www.wizards.com/default.asp?x=dnd/lists/feats . I wanted the list of feats. To get to the table, and each row of feats, here was the xPath I used:

"/html/body/table[2]/tr[2]/td[3]/table/tr[3]/td/table[4]/tr/td/table/tr"

Of particular note, I was having trouble with the tbody in xPath, so I removed those references. Let me tell you, without Firebug's copy xPath, I would've went insane getting this out.

So I ask, why the heck does Wizards of the Coast use table based layouts. They hurt my brain hurt.

If you are interested here is the code that I wrote. It doesn't have any underlying tests, but I ran the import without fail, so for now, its good enough for me.

class Feat < ActiveRecord::Base
  validates_presence_of :name, :description
  belongs_to :rule_source

  class << self
    # Run the import, first getting the RuleSources
    def import!
      File.open(File.dirname(__FILE__) + '/feats.html', 'w') do |f|
        f.puts (open("http://www.wizards.com/default.asp?x=dnd/lists/feats").read)
      end
      doc = File.open(File.dirname(__FILE__) + '/feats.html') {|f| Hpricot(f) }

      RuleSource.parse_rule_source(doc)
      
      parse_feats(doc)
    end
    private
    def parse_feats(doc)
      feats = (doc/"/html/body/table[2]/tr[2]/td[3]/table/tr[3]/td/table[4]/tr/td/table/tr")      
      feats.pop     # Get rid of the results count

      feats.each_with_index do |feat, index|
        parse_feat(feat) if index > 1
      end
    end
    def parse_feat(feat)
      ... Do the actual parsing of the row ...
    end
  end
end

class RuleSource < ActiveRecord::Base
  validates_presence_of   :code, :name

  class << self
    def parse_rule_source(doc, publisher = nil)
      (doc/"div.keyboxscroll/table/tr").each do |source|
        if source_code = (source/"td[1]")
          source_code  =  source_code.inner_html.strip
        end
        if source_name = (source/"td[2]/i")
          source_name  = source_name.inner_html.strip
        end
        
        find_or_create_by_code_and_name( source_code, source_name )
      end
    end
  end
end

Single Table Infuriation

Single Table Inheritance in Rails is an excellent pattern that works really well, except when it doesn't.

class Parent < ActiveRecord::Base
end

class Child < Parent
end

class GrandChild < Child
end

Each of the above classes are defined in their own files (app/models). There are times in development mode that I've noticed that Child.find(:all) will generate the following SQL:

SELECT * FROM parents WHERE (type='Child')

In Rails 1.2 the fix for this is perhaps a little obfuscated.

class Parent < ActiveRecord::Base
  require_dependency 'child'
end

class Child < Parent
  require_dependency 'grand_child'
end

class GrandChild < Child
end

Now, the other part of this solution is that you probably want to call require_dependency at the end of the class definition as there may be methods in the parent object that the child object needs. I suppose you could re-open the class at the end of the file.

capture, binding and other diabolical machinations

For the South Bend Ruby Group I volunteered to talk about form builders for February. At the time of volunteering, I knew close to nothing about form builders. I decided to take the upcoming meeting as a reason for learning about the builders. And now I'm hooked.

But that is not the point of this particular post. What I'm talking about is the bizarre magic involved in the form builder. In a project that I've been working on we have a need for rendering lists both in tables and in lists. However we'd really like to re-use the view logic in generating the list. Its pretty much a matter of hot-swapping the tags appropriately.

<% list_for(@list) do | l | %>
  <% l.caption 'Hello World' %>
  <% l.header_row(:id => 'list_head') do %>
    <%= l.header_cell 'title' %>
    <%= l.header_cell 'edit' %>
    <%= l.header_cell 'delete' %>
  <% end %>
  <% l.row( :class => 'spam', :id => 'hot_dog') do | list_item | %>
    <%= l.cell l.title %>
    <%= l.cell 'edit_link' %>
    <%= l.cell 'delete_link'  %>
  <% end %>
<% end %>

We opted to create a builder class. You call :list_for, and can optionally pass a builder class (like the one below). Of particular note there is use of bindings and captures. I'm still a bit dazzled by what all is going on (and wrote the tests to make sure it all works). Below is my understanding of what is going on.

1) There is the :concat method (as defined in the ActionView::Helpers::TextHelper module). We are taking the results of first parameter and appending it to the proc's binding. The proc's binding is the result of the stuff in that proc. In the case of the above :list_for its all of the text generated :list_for's block.

2) There is the :capture method (as defined in ActionView::Helpers::CaptureHelper module). This little critter packages up the input block as text. I tried using block.call but this didn't work as intended (I got double the block text). If I didn't want the option of passing options to each of the elements, I could conceptually simplify the method by doing a manual opening of a tag, block.call, then manually closing the tag. This could be a performance piece that I will implement at a later point (though I'll need a Hash#to_markup_attributes method).

def list_for(object, *args, &block)
  raise ArgumentError, "Missing block" unless block_given?
  options = args.last.is_a?(Hash) ? args.pop.symbolize_keys! : {}
  builder = options.delete(:builder) || ListTableBuilder
  builder.new(object, self, options, &block)
end

# <table>
#  <caption>
#  <tr>
#    <th />
#  </tr>
#  <tr>
#    <td />
#  </tr>
# </table>
class ListTableBuilder

  # Welcome to the insanely bizarre initialize function
  def initialize(collection, template, options, &proc)
    @collection, @template, @proc = collection, template, proc        
    @options = options.reverse_merge( :class => 'list', :id => 'list')
    @template.concat( @template.content_tag('table', @template.capture(self, &proc) , @options ), @proc.binding)
  end

  # :options are applied to content_tag('td')
  def cell(text, options = {})
    @template.content_tag('td', text, options)
  end

  # :options are applied to content_tag('th')
  def header_cell(title, options = {}) 
    @template.content_tag('th', title, options)
  end

  # :options are applied to content_tag('caption')
  def caption(text, options={})
    @template.concat( @template.content_tag('caption', text, options), @proc.binding )
  end

  # :options are applied to content_tag('tr')
  def header_row(options={}, &block)
    raise ArgumentError, "Missing block" unless block_given?
    @template.concat( @template.content_tag('tr', @template.capture(&block), options) , block.binding)
  end

  # Options
  # The options will be added to each row.  
  # :class will append and not destroy the internal classes
  # :id will be used as a prefix for the internal id generation
  def row(options={}, &block)
    raise ArgumentError, "Missing block" unless block_given?
    options.symbolize_keys!
    @collection.each do | c |
      row_options = options.reverse_merge( :class => '' )
      row_options[:class] += ' ' + @template.cycle('odd_row', 'even_row')
      row_options[:id] += '_' + @template.send(:dom_id, c)
      @template.concat( @template.content_tag('tr', @template.capture(c,  &block ), row_options), block.binding )
    end
  end
end