Category: Tutorials

One question that seems to come up a lot on the Streamlined mailing list is how best to filter the records that are displayed in the list view using a certain set of conditions. There are several ways of doing this, but the simplest way is to use Rails’ built-in scoping methods in conjunction with an around filter.

For example, say we have a Task model and a TaskController that is Streamlined-enabled. The TasksController will display a list of all Tasks in the system by default. What if we only want to display Tasks for the currently logged-in user? Something like this would work:

around_filter :scope_by_user, :only => [:list, :index]

def scope_by_user
  Task.find_with_user_scope(current_user) { yield }
end

Once this code is added to the TaskController, any calls to Task#find within the associated actions, views, and helpers will be scoped. Only tasks belonging to the current user will be listed.

What if we still want to perform an unscoped Task#find within an action? We can eliminate the scoping for a specific block of code using the #with_exclusive_scope method. It looks like this:

Task.with_exclusive_scope { code_that_should_not_be_scoped }

And that, folks, is how easy it is to filter lists in Streamlined.

I’ve been using the excellent fixture_replacement plugin for several months now and greatly prefer it over traditional fixtures (yes, even foxy fixtures). fixture_replacement2 adds even more goodness to the party. However, I ran into a problem today when trying to use default_xxx methods in my example_data.rb file:

module FixtureReplacement
  attributes_for :course do |c|
    c.name = "Geometry"
    c.transcript = default_transcript
  end
  
  attributes_for :transcript do |e|
    e.name = "Joe's Transcript"
  end
end

In “fixture_replacement language” this says that new courses should receive a default name of “Geometry” and should also receive a new transcript with a default name of “Joe’s Transcript.” The example above follows the format given in the fixture_replacement README. When I attempt to use this config file in my Rails 2.0.2 project, though, I get this error:

NameError: undefined local variable or method `default_transcript' for FixtureReplacement:Module
at top level in example_data.rb at line 7
...

Why can’t it find default_transcript? I have no idea. Digging into the source code reveals that default_transcript is added to the FixtureReplacement module at runtime, but for some reason it doesn’t ever show up as being available for calling. I don’t have the time or inclination to dig further, but I did find a workaround by changing:

c.transcript = default_transcript

to…

c.transcript = c.default_transcript

This makes fixture_replacement happy and all my tests pass. I submitted a patch so hopefully this wrinkle will be ironed out soon. But this should get you by until then.

The Rails PDF plugin is a dandy little thing. It wraps the PDF::Writer library for Ruby, allowing PDF templates to be defined like any other Rails view (with a .rpdf extension, of course).

One thing it doesn’t do is allow access to the parent controller’s helper from within a PDF template. It’s easy enough to patch the plugin to accomplish this, though.

First, open up vendor/plugins/railspdf/lib/railspdf.rb and take a gander. This is the section we’re interested in:

...
class PDFRender < ActionView::Base
  def initialize(action_view)
    @action_view = action_view
  end
  ...

PDF templates get rendered in the context of this class. All we need to do to gain access to the controller's helper here is include the helper from inside the class initializer, like so:

...
class PDFRender < ActionView::Base
  def initialize(action_view)
    @action_view = action_view
    prefix = action_view.controller.class.to_s.gsub(/Controller/, '')
    self.class.send(:include, "#{prefix}Helper".constantize)
  end
  ...

We first calculate the prefix of the helper based on the class of the controller assigned to the view. Then we include the helper in the current class by constantizing the resulting string.

We're almost done. Since ApplicationHelper should be available to every controller and helper in the system, let's include it here for good measure:

...
class PDFRender < ActionView::Base
  include ApplicationHelper
  
  def initialize(action_view)
    @action_view = action_view
    prefix = action_view.controller.class.to_s.gsub(/Controller/, '')
    self.class.send(:include, "#{prefix}Helper".constantize)
  end
  ...

And we're done! Piece of cake. Now we can reference methods from inside our controller's helper. We can, of course, modify this hack somewhat so that the same helper (something like "PdfHelper" maybe) is included for all of our templates. This enables us to isolate our PDF-specific helper methods in a single module.

And before you ask, yes, it's nasty to be modifying the plugin directly. There is a way to inject this patch into the PDFRender class without touching anything in the plugin... but I've gotta leave something for you to figure out! :)