Ryan's Scraps

For the second time I’ve had my virtual hand slapped for trumpeting a poor usage of with_scope . For the record, I want to make it clear that one should be using the rich domain model that active record provides to operate on associated objects: user.assets.find() and user.asset.create() instead of scoping to a user as my and Roman’s examples implied. Just a case of not thinking hard enough to come up with an appropriate example. Sorry David, won’t happen again!

I’ve mentioned the Meantime filter plugin by Roman Le Negrate in the past as a very useful little utility – apparently the core team agrees as around filtering is now part of edge Rails.

Usage is pretty much the same as with meantime:

class AssetController < ActionController

  before_filter :verify_login
  around_filter :benchmark

  def assets
    @assets = Asset.find(:all)
  end

  def benchmark
    benchmark("Asset benchmark") { yield }
  end

end

You can also define a class to handle your filtering needs (whose filter method yields to the action block)

class AssetController < ActionController

  around_filter BenchmarkFilter   # or BenchmarkFilter.new
  ...

  class BenchmarkFilter
    def filter
      benchmark("Benchmarking...") { yield }
    end
  end

end

Or you can directly pass a Proc in as the filter:

class AssetController < ActionController

  around_filter (:only => :assets) do |controller,action_block| 
    controller.benchmark("Benchmarking...") { action_block.call }
  end
  ...
end

Since the around filter explicitly governs the execution of the action being requested, you can use them to skip the action completely. This would act the same as a before_filter that returned false.

tags: rubyonrails, rails

I gave a short and not-very-well-prepared demo of rela.tv at the Raleigh Ruby Brigade last night that generated a few inklings of interest amongst the crowd. And I use the word “interest” generously. However, I’ve been meaning to open-source the app for awhile now since I rarely find the time to play with it anymore – if for nothing else than to see if somebody else wants to use it as a learning tools as I did and try to further its functionality.

This comes with the disclaimer that I am not proud at all of the state of the code, and especially the state of the tests. Look at this as more of an opportunity for improvement than for a model by which all others should be based.

So, if you’ve got some interest in hacking away at a cool little Rails project – let me know. I’d love to see this get taken forward a few steps…

Rela.tv source access

https://saucyworks.devguard.com/svn/projects/rela.tv/trunk

Don’t know what rela.tv is? Check out the overview for a summary.

tags: rela.tv, xfn, rails, rubyonrails

While I was being lazy Scott went ahead and posted a great write-up of the new Simply Helpful plugin that makes a few view-level operations more concise. Go ahead and check it out.

Resource feeder is no more, but the atom feed helper is here to replace it

Rails is all about some open-ness and interopability and it has become incrementally easier to achieve this with the new Resource Feeder plugin. This plugin gives you an easy way to create RSS and Atom feeds in your controllers from a collection of model objects with the use of the rss_feed_for and atom_feed_for methods:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class PostsController < ApplicationController

  # Build an rss feed
  def rss
    render_rss_feed_for Post.find(:all, :order => 'created_at DESC',
                               :limit => 10)
  end

  # Build an atom feed
  def atom
    render_atom_feed_for Post.find(:all, :order => 'created_at DESC',
                                :limit => 10)
  end

end

So how do these feed methods know how to pull information from each individual resource of the collection? It uses a combination of options passed into the feed methods and specific properties of the resource. If you don’t pass any options into these feed methods your model objects should have title, description and created_at reader methods (and updated_at for atom).

Options

There are several options you can pass into these nice little feed methods to customize the title of the feed and most of the other feed elements. Here’s my attempt at enumerating all of them for RSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Feed options (w/ defaults):
options[:feed][:title]            # Pluralization of the model class, i.e. "Posts"
options[:feed][:link]            # Url to this record
options[:feed][:description] # omitted if not specified
options[:feed][:language]    # "en-us"
options[:feed][:ttl]              # 40

# Individual item options (w/ defaults).  These are the method symbols used to
# retrieve the proper values from each individual object:
options[:item][:title]            # :title
options[:item][:description] # :description
options[:item][:pub_date]   # :created_at

# General options:
options[:url_writer]            # an instance of UrlWriter

Just pass in these options to your feed methods as needed:

1
2
3
4
5
6
7
8
9
10
11
12

class PostsController < ApplicationController

  # Build an rss feed
  def rss
    render_rss_feed_for(Post.find(:all, :order => 'created_at DESC',
                               :limit => 10),
                    { :feed => {:title => "All posts"},
                      :item => {:title => :name,
                                :pub_date => :updated_at} })
  end

end

Feelin’ sassy? Try taking advantage of this guy :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class PostsController < ActionController

  # View a collection of posts.  If "format" is specified
  # will return view of that type (of either rss or atom format)
  # /posts/list.rss => RSS
  # /posts/list.atom => Atom

  def list
    @posts = Post.find(:all, :order => 'created_at DESC',
                            :limit => 10)
    options = { :feed => {:title => "All posts"},
                    :item => {:title => :name,
                             :pub_date => :updated_at} }

    respond_to do |wants|
      wants.html
      wants.rss { render_rss_feed_for @posts, options }
      wants.atom { render_atom_feed_for @posts, options }
    end
  end
end

It just feels so right sometimes!

oh yeah, and to install this pup just do:

1
2

script/plugin install simply_helpful
script/plugin install resource_feeder

tags: rubyonrails, rails, rss, atom

This utility comes with several warnings about its experimental state and unknown future – but we’re not going to let that damper our inquisitiveness, are we? Introducing a way to execute capistrano commands from a shell environment (think script/console). So how does this Capistrano shell work?

First, start the capistrano shell w/

cap -v shell

Then enter commands to be executed on your remote environments. (These are mostly from the shell source comments itself)

# Execute on all servers
cap> echo ping

# Execute on specific servers
on myserver1.com,myserver2.com echo ping

# To execute based on roles
with app,db echo ping

# Execute a capistrano task
!deploy

# Execute multiple capistrano tasks
!setup deploy

# Combine all the goodness to execute a task on
# specific servers and roles
on myserver1.com !setup
with app !setup

Why would you want to use this shell? Well, you get the ability to simultaneously manipulate several environments from one shell – and all within the friendly confines of capistrano. You should find the rollback task to be especially comforting…

tags: rails, rubyonrails, capistrano

In what is amounting to my most useless post yet – this feature has been reverted according to Bob .

With Rails components being shunned throughout the Rails world we are often left to use a set of view partials to abstract out commonly used display functionality. Sometimes this necessitates the use of variables (called ‘locals’) that may or may not be relevant in all view scenarios. For instance, if I have a partial that I use to display form text fields there may be a size parameter I want to pass in to limit the field’s size:

# my_form.rhtml
<%= render :partial => 'text_field', :locals => {:size => 5} %>

# _text_field.rhtml
<input type="text" size="<%= size %>" />

If I want the size parameter to be optional however, I could try to do this with a default value of 5:

# _text_field.rhtml
<input type="text" size="<%= size ? size : "5" %>" />

However, this fails if no size parameter is passed to the partial as size hasn’t been defined yet. With this update, however, you can query an explicit locals hash to determine the existance of a local variable:

# _text_field.rhtml
<input type="text" size="<%= locals[:size] ? size : "5" %>" />

Not a huge update, but if you’re using partials extensively (which I suspect most are) you’ve no doubt run into this issue.

And as Bojan has pointed out you could also use the nifty defined? method

# _text_field.rhtml
<input type="text" size="<%= defined?(size) ? size : "5" %>" />

tags: rails, rubyonrails

The maturation of ActiveResource continues with a pretty significant update with “full support for find/create/update/destroy” operations.

If you’re living on the bleeding edge and have had some issues getting ActiveResource to work as advertised you may want to check out the details of this update.