Last night I tried making necessary changes to the "agnostic" branch of will_paginate so it would work with Rails 3.
My ActionView specs were failing miserably. First they wouldn't run because of this require:
That also failed with an error that ActionDispatch::Assertions::SelectorAssertions is an undefined constant. Of course it's undefined; I'm trying to require a file that defines it! This weird error seemed to originate from the very second line of code in that file:
module ActionDispatch
module Assertions # <-- this one
...
end
end
Turns out, ActionDisplatch has set "Assertions" constant to autoload 'action_dispatch/testing/assertions', which in turn tries to load all its submodules, which tried to mix in ActionDispatch::Assertions::SelectorAssertions before it's even defined [1]. The solution was to simply load the complete assertions module:
require 'action_dispatch/testing/assertions'
Now the spec suite would run, but all specs were failing. I started out with easy ones: there's an expectation that a certain view helper would raise an ArgumentError. This failed because a different error class was rescued: ActionView::TemplateError. Now, I'm aware that exceptions from view templates were wrapped in TemplateError even before Rails 3, but I have two questions: 1) why didn't I get TemplateError in previous versions of Rails, 2) why do we need to wrap view exceptions at runtime anyway?
Next, specs that assigned instance variables to a view were failing because those instance variables were nil. I was doing something in the lines of:
@view = ActionView::Base.new
# later, in example blocks:
@view.assigns[:foo] = 'bar'
# finally, when rendering
@view.render(:inline => @template, :locals => locals)
This stopped working. I investigated and I found that I have to give a complete list of assigns at instantation time:
@view = ActionView::Base.new([], @assigns)
This is because the ActionView initializer eagerly copies values from this hash to its instance variables [2]. Then it saves them to @assigns, provides an accessor for them but never does anything with that object again, so changing that hash through the accessor has no effect, although in the past it had. Is this a regression?
The rest of the failures in this test suite were all routing errors. Here is the routing setup in my tests:
ActionController::Routing::Routes.draw do |map|
map.connect 'dummy/page/:page', :controller => 'dummy'
map.connect 'dummy/dots/page.:page', :controller => 'dummy', :action => 'dots'
map.connect 'ibocorp/:page', :controller => 'ibocorp',
:requirements => { :page => /\d+/ },
:defaults => { :page => 1 }
map.connect ':controller/:action/:id'
end
The "ibocorp" route tests that if you generate a page link with {:controller => 'ibocorp', :page => 1}, because of the ":defaults" parameter you should get "/ibocorp" URL, not "/ibocorp/1". This worked in previous versions of Rails, fails in Rails 3.
Most other specs rely on the generic, ":controller/:action/:id" fallback route. They try to generate pagination links in the context of fake controller & action names and arbitrary number of additional parameters. In Rails 3, they all fail miserably with the exception like:
No route matches {:controller=>"foo", :developers_page=>1, :action=>"bar"}
This leaves me clueless. Why doesn't the generic route handle this? So far this is my biggest problem.
Finally, I had to mark all output from will_paginate view helpers as `html_safe!`. That worked like a charm.