Falling Leaves: the Ardes blog
Ian White

The first WIN for us to come out of the Rails/Merb merge is that the awesome provides API in merb (which Dan gave a compelling introduction to at RailsCamp4), has made its way to rails-3 (along with some tweaks to the API).

This is a win for us because our response_for plugin provides similar functionality (for rails 2 apps). So that's one less plugin for me to maintain.

Can't wait for RARB!

Ian White

I'm upgrading one of our apps to rails 2.2 and along with that, some plugin dependencies.

In this instance, I needed to monkey patch a method in attachment_fu to make it use the new i18n framework in Rails.

I got to thinking that it would be great if I could be reminded when this monkey patch is no longer necessary (ie. if I upgrade attachmnet_fu, and if it has made that method compatible with i18n). This was easily achieved, using rspec's pending.


pending: it's alive!

(you may want to skip straight to the pending monkey-patch stuff)

You may not know that it you pass a block to pending, it will still run that block, but it will expect it to fail. If the block passes, then rspec will tell you that the example is now working.

Here's an example: Nick is expanding on some specs for some code that I wrote.

it "fred@fang should not be a valid email" do
  @user.email = 'fred@fang'
  @user.should have(1).error_on(:email)
end

The above spec fails because currently, I don't have a complete email regexp. For whatever reason, I tell Nick that I'll look into that at some later point. What do we do next? We could open a ticket, or write a TODO, but what about that spec?

Using pending, we can add some live doco to our app:

it "fred@fang should not be a valid email" do
  pending "a better email regexp" do
    @user.email = 'fred@fang'
    @user.should have(1).error_on(:email)
  end
end

The above code will be shown as PENDING as long as the example fails. When someone gets around to writing a better regexp, the code will pass, and the rspec will fail the build telling you that the example is no longer pending.


Use pending to monitor your monkey-patches

So, we can use this neat feature of rspec to tell us when a monkey-patch is no longer required:

  • Write a spec that exhibits the desired behaviour
  • This spec should fail
  • Wrap the example(s) in pending block(s)
  • (optional, as your app specs might already test this) Write a spec that passes on the monkey-patched code.

In the example given above, all I had to do was spec out the behaviour that attachment_fu should exhibit, then wrap that in an informative pending block.

require File.dirname(__FILE__) + '/../spec_helper'

describe "attachment_fu and i18n" do
  describe "with an invalid attachment" do
    before do
      @model = mock('an attachment_fu model')
      @model.extend Technoweenie::AttachmentFu::InstanceMethods
      @model.stub!(:errors).and_return(mock('errors', :add => nil))
    
      # setup an invalid condition on the model
      @model.stub!(:attachment_options).and_return(:size => (2..3))
      @model.stub!(:size).and_return(1)
    end

    it "#attachment_attributes_valid? should not call default_error_messages" do
      pending "if this passes remove Asset#attachment_attributes_valid?" do
        ActiveRecord::Errors.should_not_receive(:default_error_messages)
        @model.send :attachment_attributes_valid?
      end
    end
  end
end

This means that if I upgrade to a version of attachment_fu that fixes the above problem, my specs will tell me my monkey-patch is no longer required.

refactorin' VC, 64 stylee

December 1st, 2008

Ian White

After railscamp#4, I went to #rorosyd's November meetup which experimented with 2 sessions of 6 lightning talk's, and was GREAT (but the lack of time for questions was not so great).

I gave one on refactoring VC (as in MVC) with response_for and inherit_views. For some reason, I had a serious bout of nostalgia as I was preparing the talk and came up with this (watch the for the 'bytes free' automatic countdown). If that pisses you off, then the slides will piss you off slightly less.

tabtab - freakin awesome!

November 23rd, 2008

Ian White

One of the projects to come out of RailsCamp 4 (photos) (well apparently it started on the flight from Birsbane) is Dr Nic's super awesome autocompletions - tabtab.

It's basically context sensitive autocompletion for your ruby (and shell) world (and you can add your own completions). Think git-bash-autocompletion - for everything! To get it installed:

sudo gem install tabtab
install_tabtab

Finally, add source ~/.tabtab.bash to the bottom of your ~/.profile

Here's an example of its use - using the github gem to checkout forks of one of my projects.


Adding your own completions

tabtab has a snazy ruby dsl to add completions. I tried adding them for the CI tool garlic and it took a whole minute!.

This was due to the fact you tabtab will parse your help file (if you tell it to) for the command line options, and the fact that I already had an abstraction in garlic to introspect the command-line/rake-tasks. If you don't have the latter it would take maybe 2 whole minutes.

After I pushed garlic, and on reinstall, I just had to run install_tabtab to have the garlic tabtab def automagically appear in my ~/.tabtab.bash.

Check out the comprehensive README. Thanks Dr Nic!

Nick Rutherford

This is a really good way of doing CI testing, as when you break your spec tests you'll get notified about it by Growl, and whatever image you chose (be it Bob the builder, Mr T, or whoever scares you ;).

I stepped through this process recently and hit on some snags so thought I'd list a process here. I'm on Leopard 10.5.5 using the Apple Ruby install.

Read the rest of this entry
Ian White

Rails edge is getting lots of changes under the hood, consequently garlic has been kicking up a fuss for response_for and inherit_views...

So, I've rewritten them! Both plugins are now a lot cleaner, and have less LOC, due to some great changes under the actionpack hood.

inherit_views | response_for

inherit_views is a pretty simple concept. When you subclass a controller in rails, it would be great if you controller inherited its views from the the view path of the superclass controller. Here's how to use it (or you can just Skip ahead to the rewrite).

Using inherit_views

If you want every controller to inherit it's views from parent controllers, then do this:

class ApplicationController < ActionController::Base
  inherit_views

I think this is generally a bad idea, I use inherit views when I need to (when I subclass a controller):

class AccountImagesController < ImagesController
  inherit_views 'images'

When you use inherit_views, all view types are supported, as are partials. This means that with the following setup:

images/_form.html.erb
images/edit.html.erb

account_images/_form.html.erb

rendering 'edit' from AccountImages controller will render account_images/_form.html.erb inside images/edit.html.erb.

Rewriting inherit_views for edge

The inherit_views plugin used to acheive this by alias_method_chaining render on the controller and the view, and it would substitute an inherited view if the standard view couldn't be found. Along the way, it got patched for various changes in the rails internal, and well... it got pretty messy.

Edge rails has had a lot of template love recently, and one of the great things is that the notion of picking a template to render now has a single point of entry: ActionView::Base#_pick_template. (there is also _pick_partial_template, but that just massages the filename into the partial format, then calls _pick_template).

This made me stoked because all of the shennanigans in inherit_views could be swept away, and replaced with #_pick_template_from_inherit_view_paths. The only thing left for the plugin to do is to manage the inherit view paths (these are stored on the controller).

A note for current inherit_views users, I've removed some of the API which I never used (render_parent, and some other things). Let me know if you really need that stuff...

inherit_views | response_for

Ian White

Rails edge is getting lots of changes under the hood, consequently garlic has been kicking up a fuss for response_for and inherit_views...

So, I've rewritten them! Both plugins are now a lot cleaner, and have less LOC, due to some great changes under the actionpack hood.

inherit_views | response_for

Summary: response_for lets you specify a default response for an action. If that action (or a before_filter) doesn't perform a render or redirect, then the default response is rendered. You can also 'stack' responses - the latter ones override the former ones.

To get the full benefit of response_for, you need to write your actions with it in mind. It's not allways appropriate - but for some things it's great. if you have a set of actions that you use a lot (say if you're a resources_controller user), or if you use superclass controllers, then you'll probably get some benefits form response_for.

Before talking about the rewrite, I'll just give a before and after example of a common use case for response_for - subclassed controller action. If you want to skip this just head straight to the section regarding the rewrite.

Before

Here is a fairly standard controller with an action that does some stuff, then conditionally renders a response.

class SuperclassController < ApplicationController
  # the action does some stuff, then conditionally renders a repsonse
  # for :html, and :js
  def the_action
    do_some_stuff
   
    did_yet_more_stuff = if do_some_more_stuff
      do_yet_more_stuff
    else
      do_the_other_thing
    end
   
    respond_to do |format|
      if did_yet_more_stuff
        format.html do
          flash[:notice] = "Well done you"
          redirect_to the_done_url
        end
        format.js
      else
        format.html do
          flash[:notice] = "Bad boy"
          redirect_to the_bad_url
        end
        format.js { render :action => 'the_action' }
      end
    end
  end
end


There are two main reasons to override this action in a subclassed controller, (i) to change the response, and (ii) to change the logic. Both of these require a rewrite of the entire action! This is painful.

Code speaks louder than words, so here are two subclassed controllers, both of which add authentication, one which chnages the html response on success, the other which changes the logic. Click here to skip the code.

class Subclass1Controller < SuperclassController
  # We add authentication, and change the response
  before_filter :require_login
 
  def the_action
    do_some_stuff
   
    did_yet_more_stuff = if do_some_more_stuff
      do_yet_more_stuff
    else
      do_the_other_thing
    end
   
    respond_to do |format|
      if did_yet_more_stuff
        format.html do
          # We change the response
          flash[:notice] = "Well done #{current_user.display_name}"
          redirect_to the_done_url
        end
        format.js
      else
        format.html do
          flash[:notice] = "Bad boy"
          redirect_to the_bad_url
        end
        format.js { render :action => 'the_action' }
      end
    end
  end
end


class Subclass2Controller < SuperclassController
  # We add authentication, and change the logic
  before_filter :require_login
 
  def the_action
    do_some_stuff
   
    # Here we change the logic, but we have to write out the response again
    did_yet_more_stuff = if do_some_more_stuff_for_user(current_user)
      do_yet_more_stuff
    else
      do_the_other_thing
    end
   
    respond_to do |format|
      if did_yet_more_stuff
        format.html do
          flash[:notice] = "Well done you"
          redirect_to the_done_url
        end
        format.js
      else
        format.html do
          flash[:notice] = "Bad boy"
          redirect_to the_bad_url
        end
        format.js { render :action => 'the_action' }
      end
    end
  end
end


After..

Here's the same effect, with response for. We do need to write the superclass action a little differently first. We just take the response out of the action. We need to add an instance variable, so the response can conditionally render different things.

class SuperclassController < ApplicationController
  # this time with response_for
  def the_action
    do_some_stuff
   
    @did_yet_more_stuff = if do_some_more_stuff
      do_yet_more_stuff
    else
      do_the_other_thing
    end
  end
 
  response_for :the_action do |format|
    if @did_yet_more_stuff
      format.html do
        flash[:notice] = "Well done you"
        redirect_to the_done_url
      end
      format.js
    else
      format.html do
        flash[:notice] = "Bad boy"
        redirect_to the_bad_url
      end
      format.js { render :action => 'the_action' }
    end
  end
end

Now, our two subclassed controllers look like this:

class Subclass1Controller < SuperclassController
  # We add authentication, and change the response
  before_filter :require_login
 
  # we only override the repsonse that has changed
  response_for :the_action do |format|
    if @did_yet_more_stuff
      format.html do
        flash[:notice] = "Well done #{current_user.display_name}"
        redirect_to the_done_url
      end
    end
  end
end


class Subclass2Controller < SuperclassController
  # We add authentication, and change the logic
  before_filter :require_login
 
  def the_action
    do_some_stuff
   
    # Here we change the logic, we don't need to touch the response
    @did_yet_more_stuff = if do_some_more_stuff_for_user(current_user)
      do_yet_more_stuff
    else
      do_the_other_thing
    end
  end
end


The rewrite

The original response_for had to do some pretty tricky messin about to kick in once the action had done its thing. Things got a whole lot easier when actionpack introduced the default_render hook.

default_render is called after your action if a response has not explicitly been rendered (or redirected). You can use this yourself in your controllers if you want to do something other than just rendering the default template. response_for alias_method_chains it to render any declared responses..

If you're a previous response_for user

Along with the rewrite, I changed the way repsonse_for works. It used to intercept respond_to, so that you could override any repsonse declared in your action. This resulted in a bunch of weird edge cases, and so I decided to ditch it (read more about this at the end of the response_for README). If you need the old functionality use the 0.1-stable branch.

inherit_views | response_for

RailsConf Talk

September 12th, 2008

Ray Drainville

My business partner Ian White is is a very busy man. Currently, he’s just arrived in his native Australia, but only a few days ago he attended & gave a talk at RailsConf Europe—you can find the précis for his talk, Writing Resources_Controller: Discovering REST Patterns in Rails, on their site.

Once he’s recovered from his jet lag, Ian’s planning on giving some more information on his talk here. Stay tuned!

Update

The slides have finally appeared on the oreilly RailsConfEurope page (near the bottom).

Ian White

Update: check out Nick's latest post for up to date info.


There's a bunch of articles that helpfully diagnose and solve the GRRRRowl + autotest + Leopard snafu.

In order to save me, and my cohorts, some time I've bundled it all up in a README + script + icons.

Being a new father, currently at my in-laws, I've reached for the nearest toy, and made bob the builder icons. I think they might even challenge hookercookerman's set (sadly, not on the web as afar as I can see - step up hookercookerman and post them).

Grab it

here (tarball, installation instructions inside)

P.S.

I made the screenshots with Photo booth's 'backdrop' feature, and a real toy. Finally, I can do composites (I just knew not learning photoshop would pay off).

resources_controller: things

April 27th, 2008

Ian White

RC's got a github home now

The subversion repo will still continue to be maintained for the foreseeable future.

RC's also reported as being one of the things under the hood at naked.

Lastly, I've been cooking my CI with garlic.

Ian White

So I've been curled up in a ball, riding the git avalanche, trying to sort out my rails plugins - making sure they're getting tested against the latest and greatest.

Inspired by this ticket for rspec, git's coolness, some menthol snuff, and a lot of coffee, I came up with garlic.

It's an extremely lightweight set of rake tasks that let you test your plugins or app against various version of rails, and other dependencies.

If you want to see it in action (on one of my plugins), do this:

  git clone git://github.com/ianwhite/inherit_views
  cd inherit_views
  rake cruise

Sit back, watch it download all the dependencies, then create rails apps for each set, and run the rcov task for the plugin in each one... (the download only happens the first time you do it).

You configure it using a little dsl, like this:

garlic do
  # default paths are 'garlic/work', and 'garlic/repos'
  work_path "tmp/work"
  repo_path "tmp/repos"
  
  # repo, give a url, specify :local to use a local repo (faster
  # and will still update from the origin url)
  repo 'rails', :url => 'git://github.com/rails/rails' #, :local => "~/dev/vendor/rails"
  repo 'rspec', :url => 'git://github.com/dchelimsky/rspec'
  repo 'rspec-rails', :url => 'git://github.com/ianwhite/rspec-rails'
  repo 'inherit_views', :url => '.'
  
  # for target, default repo is 'rails', default branch is 'master'
  target 'edge'
  target '2.0-stable', :branch => 'origin/2-0-stable'
  target '2.0.2', :tag => 'v2.0.2'
  
  all_targets do
    prepare do
      plugin 'rspec'
      plugin 'rspec-rails', :branch => 'origin/aliased-render-partial' do
        sh "script/generate rspec -f"
      end
      plugin 'inherit_views'
    end
    
    run do
      cd "vendor/plugins/inherit_views" do
        sh "rake spec:rcov:verify"
      end
    end
  end
end

Notice that I'm using my fork of rpsec-rails, and the plugin specifies that it should use a particular branch 'aliased-render-partial'. The reason for this is that I have some outstanding tickets on rspec, which haven't been resolved. In the meantime, I can just use my patched version. If the patch gets accepted, I can just change the url, and garlic will inform me that I need to remove and run rake garlic:install_repos to get the new one. This is just making use of the awesomely cool coolness of git.

Also notice the block passed to the 'rspec-rails' plugin. This will be executed inside the rails target after the plugin has been installed. Finally the run block says what should happen for the actual CI. In this case cding into the plugin and running an rcov task.

It's new stuff

So it probably has bugs and stuff.

resources_controller new trunk

February 26th, 2008

Ian White

There's going to be some new features coming in resources_controller. Stay tuned...

Meanwhile, rc has got a new repository location (the old one will still work for a while, but will remain at the current version):

trunk: http://svn.ardes.com/resources_controller/trunk/resources_controller

tag 0.5: http://svn.ardes.com/resources_controller/tags/0.5/resources_controller

For those interested in providing patches, you should checkout http://svn.ardes.com/resources_controller/trunk and run rake pre_commit in that directory to check your changes. Then send a diff along, or post it on the google group.

Why I love Safari Tidy

November 23rd, 2007

Ray Drainville

Recently I mentioned that I use Safari Tidy—a plugin for Apple’s Safari browser. I thought I’d shed a little light on why I think it’s so great.

For years now individuals—Jeffrey Zeldman most prominent among them—have been evangelising the use of standards-based (X)HTML. There are vague reasons for supporting standards, like getting the warm & fuzzies for doing so; there are abstract reasons, such as preparing work properly to be handed over to a successor; but a very real & immediate reason is that you have a very firm basis upon which to work. It’s all too easy to make mistakes in the semantic properties of HTML, which can yield disastrous rendering results in browsers. And it’s all too easy to not see the problem until late in your design process.

Safari Tidy is unobtrusive & always on: you’ll see that an error has arisen immediately, so you can go fix it. Other implementations of Tidy aren’t so automatic—you have to physically check your markup’s validity, which often means that you don’t check—this is what makes Safari Tidy so fantastic.

I’ll illustrate with a real-world example (one upon which I’m currently working, in fact):

Many out there will be aware of the generating capabilities of Ruby on Rails. A good explanation of this is beyond the scope of this article, but suffice to say you can build the general building-blocks of a web application very quickly, such as setting up a new user in a system. Here’s a rudimentary example of a ready-built form (linked to the users controller). It’s to be rendered in XHTML:

  <% form_for(@user) do |f| %>

    <p>
      Login:<br />
      <%= f.text_field :login %>
    </p>

    <p>
      Email:<br />
      <%= f.text_field :email %>
    </p>

    <p>
      Password:<br />
      <%= f.text_field :password %>
    </p>

    <p>
      <%= submit_tag %>
    </p>

  <% end %>
  

The result of all that <%= f.text_field :foo %> is to create form tags, such as input. Here’s what the above gets with the Login example:

  <p>
    Login:<br />
    <input id="user_login" name="user[login]" size="30" />
  </p>

So far, so good. But what if the user hasn’t filled out a field & you have to display associated errors? Simple in Ruby on Rails. Assuming validation has been set up in your users controller, just add the following bit in front of your form:

  <%= error_messages_for :users %>

With this in place, if your user doesn’t enter a required field, or enters a required field incorrectly, then Rails will automatically inform the user of what was wrong (in the location of the <%= error_messages_for :users %>). Moreover, it’ll wrap the offending field to highlight the user’s attention to it. It will look like this:

  <p>
    Login:<br />
    <div class="fieldWithErrors">
      <input id="user_login" name="user[login]" size="30" />
    </div>
  </p>

And now we have a problem. A div can contain a p, but cannot be contained within it. This is where Safari Tidy comes in really handy. When you test your error message (as above) by viewing it in Safari, Safari Tidy will inform you of an error in your markup. The error it makes is somewhat cryptic:

  <p>
    Login:<br /> 
    <div class="fieldWithErrors">
      <input id="user_login" name="user[login]" size="30" type="text" value="" />
    </div>
  </p>
  -----
  Line 85  Warning: inserting implicit <p>
  Line 89  Warning: trimming empty  <p>

What’s going on here? Since a p can’t contain a div, Tidy thinks you’ve not closed your p tag before you started your div. In addition, it thinks you haven’t opened your p after you’ve closed your div tag. Certainly, knowing your XHTML helps in this situation, since the error it throws is otherwise cryptic; but Tidy gives the clue where to find the error. On a form with a lots of fields, this is really helpful.

Safari Tidy helped me note there was a problem before I even realised that there was a problem—and there really was, the error screwed up my pretty design horribly.

Update: What a wally—I got so wrapped up in Safari Tidy that I didn’t explain how to fix the error! There’s a simple solution: convert your p tags to divs throughout. I don’t know why Rails screws this up in the first place—Rails seems to have been designed pretty well & this is a glaring oversight. It’s really bothersome to have to fix every automatically-generated form.

response_for_resources_controller

November 20th, 2007

Ian White

If you're using response_for, then you might want to grab response_for_resources_controller

It simply replaces the default action modules with ones that use the response_for idiom.

This means that you can override what an action does without overriding how it responds. For example, I want a standard REST controller, that sets a protected attribute, user, on create.

class PostsController < ApplicationController
  resources_controller_for :posts

  def create
    self.resource = new_resource
    resource.user = current_user
    save_resource
  end # the standard response_for :create is used
end

If you don't know what response_for does, it lets you declaratively set the respond_to of an action. For example: if you want to override some aspect of the response, here I just want to change the flash message on successful create:

class LoginsController < ApplicationController
  resources_controller_for :logins

  response_for :create do |format|
    format.html { flash[:notice = "You have logged in" } if resource_saved?
  end
end

miscellany

I added save_resource and resource_saved? to rc, as a way of sharing the result of the save outside the scope of the action. Previously I've done this with valid?, but realised that this might hit the database unnecessarily in some circumstances. You can use either idiom.

Ian White

If you've ever subclassed a controller to deal with a particular MIME type, say FBML, you will have had the painful experience of having to copy and paste all of your contoller's actions, adding, or replacing the fbml blocks into the code.

This doesn't feel right - and it isn't. If you have to change some controller logic - you have to remember to change it in all these subclassed controllers.

Enter response_for (rdoc here).

response_for lets you declaratively specify how your actions should respond to particular Mime types. This helps particularly when your action's logic is not simple (like a CRUD action - but it still helps there). Here's an example I just made up:

class ReportController < ApplicationController
  # this puppy gets some models to collaborate to form a report
  def report
    @report = {}
    @report[:invoiced] = Customer.find_invoiced
    @report[:outstanding] = @report[:invoiced].select {|c| c.latest_invoice.outstanding? }
      
    respond_to do |format|
      format.html 
      format.xml { # some funky xml stuff here }
    end
  end
end

Let's say I wanted to make FBML responding version of this controller, normally, I'd have to copy/paste this action and add the fbml responses. With response_for, I do this:

  class FacebookReportController < ReportController
  response_for :report do |format|
    format.fbml { # my funky fbml stuff here, accessing @report}
  end
end

So, down the line, if I change the way my @report object is generated, I don't have to change my subclassed controllers.

Another example: create

You can choose to replace the respond_to block of the action as well. This means that common actions can be written, and the response can be adjusted according to your needs (resources_controller comes to mind).

Here's a standard create action:

class ForumsController < ApplicationController
  def create
    @forum = Forum.new(params[:forum])
    @forum.save
      
    respond_to do |format|
      if @forum.valid?
        flash[:notice] = 'Forum was successfully created.'
        format.html { redirect_to(@forum) }
        format.xml  { render :xml => @forum, :status => :created, :location => @forum }
      else
        format.html { render :action => "new" }
        format.xml  { render :xml => @forum.errors, :status => :unprocessable_entity }
      end
    end
  end
end

Let's say you want to create an FBML only version of this:

class FacebookForumsController < ForumsController
  response_for :create, :replace => true do |format|
    if @forum.valid?
      format.fbml { # funky fbml stuff for valid record }
    else
      format.fbml { # and for an invalid record}
    end
  end
end

One last example

For many actions, you just want to tell your action to respond to particular MIME type and a template does the rest:

class FacebookUsersController < UsersController
  response_for :index, :show, :types => [:fbml]
  end

You don't need to have a respond_to block defined in your actions - the parent controller could look like:

class UsersController < ApplicationController
  def index
    @users = User.find :all
  end
  
  def show
    @user = User.find params[:id]
  end
end

resources_controller + response_for

For those users of resources_controller, response_for gives you an easy way of adding responses on an ad-hoc basis (like if only one or two of your actions need to be RSS feeds or summat)

This is the first release...

and I welcome any bug reports