Simple Example of Dependency Injection with Rails

Today I came across a great opportunity to illustrate dependency injection in a simple context. I had a Rails partial that was duplicated across two subclasses. The partial was responsible for displaying options to create a new record from the data of the current record. It also offered two types of copy, shallow and deep. The shallow copy used a button to POST data, while the deep copy offered a form with some additional options. The only difference between the partials was the path to post data to. Let's see this in code.

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

#app/views/fun_event/_copy_options.html.erb button_to(t("create_and_edit_shallow_copy"), fun_event_path(:from_event => @event.id, :return => true), :    id => "shallow_copy_btn")   form_tag(fun_event_path(:return => true)) do   #form code end     #app/views/boring_event/_copy_options.html.erb button_to(t("create_and_edit_shallow_copy"), boring_event_path(:from_event => @event.id, :return => true), :    id => "shallow_copy_btn")   form_tag(boring_event_path(:return => true)) do   #form code end

The first, failed iteration

To remove the duplication, I passed in a path option into the partial, replacing specific references with the generic.

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

#app/views/fun_events/copy.html.erb <%= render :partial => "events/copy_options", :event_path => fun_event_path %>     #app/views/boring_events/copy.html.erb <%= render :partial => "events/copy_options, :event_path => boring_event_path %>   #app/views/events/_copy_options.html.erb button_to(t("create_and_edit_shallow_copy"), event_path(:from_event => @event.id, :return => true), :    id => "shallow_copy_btn")   form_tag(event_path(:return => true)) do   #form code end

Can you guess where this led?

undefined method `event_path' for ActionView::Base:0xd6acf18

Dude! Inject the dependency!

Obviously the event_path variable I was passing was a string, not a method. I needed the method so I could pass in the appropriate arguments to construct the URL I needed. Had there not been two different calls to the routes, I would likely have just passed in the string needed in each context. But in this case, I was forced to think outside the box. Here's what I ended up with.

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

#app/views/fun_events/copy.html.erb <%= render :partial => "events/copy_options", :event_path => method(:fun_event_path) %>     #app/views/boring_events/copy.html.erb <%= render :partial => "events/copy_options, :event_path => method(:boring_event_path) %>   #app/views/events/_copy_options.html.erb button_to(t("create_and_edit_shallow_copy"), event_path.call(:from_event => @event.id, :return => true), :    id => "shallow_copy_btn")   form_tag(event_path.call(:return => true)) do   #form code end

The changes are really quite subtle, but we use Object's method method to pass the reference to the method we want to call, and simply pass in the arguments when needed. Mind == Blown

Using Disqus and Ruby on Rails

Recently, I posted about how to import comments from a Ruby on Rails app to Disqus. This is a follow up to that post where I outline the implementation of Disqus in a Ruby on Rails site. Disqus provides what it calls Universal Code which can be added to any site. This universal code is just JavaScript, which asynchronously loads the Disqus thread based on one of two unique identifiers Disqus uses.

Disqus in a development environment

Before we get started, I'd recommend that you have two Disqus "sites"; one for development and one for production. This will allow you to see real content and experiment with how things will really behave once you're in production. Ideally, your development server would be publicly accessible to allow you to fully use the Disqus moderation interface, but it isn't required. Simply register another Disqus site, and make sure that you have your shortname configured by environment. Feel free to use whatever method you prefer for defining these kinds of application preferences. If you're looking for an easy way, considering checking out my article on Working with Constants in Ruby. It might look something like this:

1 2 3

# app/models/article.rb   DISQUS_SHORTNAME = Rails.env == "development" ? "dev_shortname".freeze : "production_shortname".freeze

Disqus Identifiers

Each time you load the universal code, you need to specify a few configuration variables so that the correct thread is loaded:

• disqus_shortname: tells Disqus which website account (called a forum on Disqus) this system belongs to.
• disqus_identifier: tells Disqus how to uniquely identify the current page.
• disqus_url: tells Disqus the location of the page for permalinking purposes.

Let's create a Rails partial to set up these variables for us, so we can easily call up the appropriate comment thread.

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

# app/views/disqus/_thread.html.erb # assumes you've passed in the local variable 'article' into this partial # from http://docs.disqus.com/developers/universal/   <div id="disqus_thread"></div> <script type="text/javascript">       var disqus_shortname = '<%= Article::DISQUS_SHORTNAME %>';     var disqus_identifier = '<%= article.id %>';     var disqus_url = '<%= url_for(article, :only_path => false) %>';       /* * * DON'T EDIT BELOW THIS LINE * * */     (function() {         var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;         dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';         (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);     })(); </script>

The above code will populate the div#disqus_thread with the correct content based on your disqus_identifier. By setting up a single partial that will always render your threads, it becomes very easy to adjust this code if needed.

Disqus Identifier Gotcha

We found during our testing a surprising and unexpected behavior in how Disqus associates a thread to a URL. In our application, the landing page was designed to show the newest article as well as the Disqus comments thread. We found that once a new article was posted, the comments from the previous article were still shown! It seems Disqus ignored the unique disqus_identifier we had specified and instead associated the thread with the landing page URL. In our case, a simple routing change allowed us to forward the user to the unique URL for that content and thread. In your case, there may not be such an easy work around, so be certain you include both the disqus_identifier and disqus_url JavaScript configuration variables above to minimize the assumptions Disqus will make. When at all possible, always use unique URLs for displaying Disqus comments.

Comment Counters

Often an index page will want to display a count of how many comments are in a particular thread. Disqus uses the same asynchronous approach to loading comment counts. Comment counts are shown by adding code such as the following where you want to display your count:

1 2 3 4 5 6 7 8 9 10

# HTML <a href="http://example.com/article1.html#disqus_thread"    data-disqus-identifier="<%=@article.id%>"> This will be replaced by the comment count </a>   # Rails helper <%= link_to "This will be replaced by the comment count",     article_path(@article, :anchor => "disqus_thread"),     :"data-disqus-identifer" => @article.id %>

At first this seemed strange, but it is the exact same pattern used to display the thread. It would likely be best to remove the link text so nothing is shown until the comment count is loaded, but I felt for my example, having some meaning to the test would help understanding. Additionally, you'll need to add the following JavaScript to your page.

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

# app/view/disqus/_comment_count_javascript.html.erb # from http://docs.disqus.com/developers/universal/ # add once per page, just above </body>   <script type="text/javascript">          var disqus_shortname = '<%= Article::DISQUS_SHORTNAME %>';       /* * * DON'T EDIT BELOW THIS LINE * * */     (function () {         var s = document.createElement('script'); s.async = true;         s.type = 'text/javascript';         s.src = 'http://' + disqus_shortname + '.disqus.com/count.js';         (document.getElementsByTagName('HEAD')[0] || document.getElementsByTagName('BODY')[0]).appendChild(s);     }()); </script>

Disqus recommends adding it just before the closing </body> tag. You only need to add this code ONCE per page, even if you're planning on showing multiple comment counts on a page. You will need this code on any page with a comment count, so I do recommend putting it in a partial. If you wanted, you could even include it in a layout.

Styling Comment Counts

Disqus provides extensive CSS documentation for its threads, but NONE for its comment counters. In our application, we had some very particular style requirements for these comment counts. I found that in Settings > Appearance, I could add HTML tags around the output of the comments.

This allowed me to style my comments as needed, although these fields are pretty small, so make sure to compress your HTML as much as possible.

Importing Comments into Disqus using Rails

It seems everything is going to the cloud, even comment systems for blogs. Disqus is a platform for offloading the ever growing feature set users expect from commenting systems. Their website boasts over a million sites using their platform and offers a robust feature set and good performance. But before you can drink the Kool-Aid, you've got to get your data into their system.

If you're using one of the common blog platforms such as WordPress or Blogger, there are fairly direct routes Disqus makes available for automatically importing your existing comment content. For those with an unsupported platform or a hand-rolled blog, you are left with exporting your comments into XML using WordPress's WXR standard.

Disqus leaves a lot up to the exporter, providing only one page in there knowledge base for using what they describe as a Custom XML Import Format. In my experience the import error messages were cryptic and my email support request is still unanswered 5 days later. (Ok, so it was Christmas weekend!)

So let's get into the nitty gritty details. First, the sample code provided in this article is based on Rails 3.0.x, but should work with Rails 3.1.x as well. Rails 2.x would work just as well by modifying the way the Rails environment is booted in the first lines. I chose to create a script to dump the output to standard output which could be piped in to a file for upload. Let's see some of the setup work.

Setting up a Rails script

I choose to place the script in the RAILS_ROOT/scripts directory and named it wxr_export.rb. This would allow me to call the script with the Rails 2.x style syntax (ahh, the nostalgia):

1	script/wxr_export.rb > comments.xml

This would fire up the full Rails enviornment, execute our Ruby code, and pipe the standard output to a file called comments.xml. Pretty straightforward, but it's not that often Rails developers think about creating these kind of scripts, so it's worth discussing to see the setup mechanics.

1 2 3

#!/usr/bin/env ruby require File.expand_path('../../config/boot', __FILE__) require File.expand_path('../../config/environment', __FILE__)

I think the first line is best explained by this excerpt from Ruby Programming:

First, we use the env command in the shebang line to search for the ruby executable in your PATH and execute it. This way, you will not need to change the shebang line on all your Ruby scripts if you move them to a computer with Ruby installed a different directory.

The next two lines are essentially asking the script to boot the correct Rails environment (development, testing, production). It's worth briefly offering an explanation of the syntax of these two somewhat cryptic lines. File#expand_path converts a pathname to an absolute pathname. If passed only the first string, it would use the current working path to evaluate, but since we pass __FILE__ we are asking it to use the current file's path as the starting point.

The config/boot.rb file is well documented in the Rails guides which explains that boot.rb defines the location of your Gemfile, hooks up Bundler, which adds the dependencies of the application (including Rails) to the load path, making them available for the application to load.

The config/enviornment.rb file is also well documented and effectively loads the Rails packages you've specified, such as ActiveModel, ActiveSupport, etc...

Exporting WXR content

Having finally loaded our Rails enviornment in a way we can use it, we are ready to actually build the XML we need. First, let's setup our XML and the gerenal format we'll use to popualate our file:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

# script/wxr_export.rb   xml = Builder::XmlMarkup.new(:target => STDOUT, :indent => 2)   xml.instruct! :xml, :version=>"1.0", :encoding=>"UTF-8"   xml.rss 'version' => "2.0",         'xmlns:content' => "http://purl.org/rss/1.0/modules/content/",         'xmlns:dsq' => "http://www.disqus.com/",         'xmlns:dc' => "http://purl.org/dc/elements/1.1/",         'xmlns:wp' => "http://wordpress.org/export/1.0/" do      xml.channel do     Articles.all.each do |article|       if should_be_exported?(article)         xml.item do             #Article XML goes here      article.comments.each do |comment|              #Comments XML goes here      end #article.comments.each  end   #xml.item       end     #if should_be_exported?     end       #Articles.all.each   end         #xml.channel end           #xml.rss

This is the general form for the WXR format as described by Disqus's knowledge base article. Note that you need to nest the comments inside each specific Article's XML. I found that I needed to filter some of my output so I added a helper function called should_be_exported? which can be defined at the top of the script. This would allow you to exclude Articles without comments, or whatever criteria you might find helpful.

With our basic format in place, let's look at the syntax for exporting the Article fields. Keep in mind that the fields you'll want to pull from in your system will likely be different, but the intention is the same.

Inside the Article XML block

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

# script/wxr_export.rb   # Inside the Article XML block   xml.title article.title   xml.link create_url_for(article)   xml.content(:encoded) { |x| x << "<!--[CDATA[" + article.body + "]]-->" }   xml.dsq(:thread_identifier) { |x| x << article.id }   xml.wp(:post_date_gmt) { |x| x << article.created_at.utc.to_formatted_s(:db) }   xml.wp(:comment_status) { |x| x << "open" } #all comments open

Let's look at each of these fields one by one:

• xml.title: This is pretty straight forward, just the plain text tile of the blog article.
• xml.link: Disqus can use URLs for determining which comments to display on your page, so it asks you to provide a URL associated with this article. I found that for this particular app, it would be easier to write another helper function to generate the URLs then using the Rails routes. If you wish to use the Rails routes (and I suggest you do), then I suggest checking out this excellent post for using routes outside of views.
• xml.content(:encoded): The purpose of this field is clear, but the syntax is not. Hope this saves you some time and headache!
• xml.dsq(:thread_identifier): The other way Disqus can identify your article is by a unique identifier. This is strongly recommended over the use of a URL. We'll just use your unique identifier in the database.
• xml.wp(:post_date_gmt): The thing to keep in mind here is that we need the date in a very particular format. It needs to be in YYYY-MM-DD HH:MM:SS 24-hour format and adjusted to GMT which typically implies UTC. Rails 3 makes this very easy for us, bless their hearts.
• xml.wp(:comment_status): This app wanted to leave all comments open. You may have different requirements so consider adding a helper function.

Inside the Comment XML block

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

article.comments.each do |comment|       xml.wp(:comment) do       xml.wp(:comment_id) { |x| x << comment.id }       xml.wp(:comment_author) do |x|       if comment.user.present? && comment.user.name.present?         x << comment.user.name       else  x << ""       end     end                         xml.wp(:comment_author_email) do |x|       if comment.user.present? && comment.user.email.present?         x << comment.user.email       else         x << ""       end     end       xml.wp(:comment_author_url) do |x|       if comment.user.present? && comment.user.url.present?         x << comment.user.url       else         x << ""       end     end       xml.wp(:comment_author_IP) { |x| x << "255.255.255.255" }       xml.wp(:comment_date_gmt) { |x| x << comment.created_at.utc.to_formatted_s(:db) }       xml.wp(:comment_content) { |x| x << "<!--[CDATA[" + comment.body + "]]-->" }       xml.wp(:comment_approved) { |x| x << 1 } #approve all comments       xml.wp(:comment_parent) { |x| x << 0 }     end #xml.wp(:comment) end #article.comments.each

Again, let's inspect this one field at a time:

• xml.wp(:comment_id): Straightforward, a simple unique identifier for the comment.
• xml.wp(:comment_author): Because some commentors may not have a user associated with them, I added some extra checks to make sure the author's user and name were present. I'm sure there's a way to shorten the number of lines used, but I was going for readability here. I'm not certain it was necessary to include the blank string, but after some of the trouble I had importing, I wanted to minimize the chance of strange XML syntax issues.
• xml.wp(:comment_author_email): More of the same safe guards of having empty data.
• xml.wp(:comment_author_url): More of the same safe guards of having empty data.
• xml.wp(:comment_author_IP): We were not collecting user IP data, so I put in some bogus data which Disqus did not seem to mind.
• xml.wp(:comment_date_gmt): See xml.wp(:post_date_gmt) above for comments about date/time format.
• xml.wp(:comment_content): See xml.content(:encoded) above for comments about encoding content.
• xml.wp(:comment_approved): Two options here, 0 or 1. Typically you'd want to automatically approve your existing comments, unless of course you wanted to give a moderator a huge backlog of work.
• xml.wp(:comment_parent): This little field turned out to be the cause of a lot of trouble for me. In the comments on Disqus's XML example, it says parent id (match up with wp:comment_id), so initially, I just put in the comment's ID in this field. This returned the very unhelpful error * url * URL is required to which I still have my unanswered supprot email in to Disqus. By trial error, I found that by just setting the comment_parent to zero, I could successfully upload my comment content. If you are using threaded comments, I suspect this field will be of more importance to you then it was to me. When I hear from Disqus, I will update this article with more information.

Performing Bulk Edits in Rails: Part 2

This is the second article in the series on how to perform a bulk edit in Rails. Let's recap our user's story from Part 1.

• User makes a selection of records and clicks "Bulk Edit" button
• User works with the same form they would use for a regular edit, plus
• check boxes are added by each attribute to allow the user to indicate this variable should be affected by the bulk edit
• only attributes which are the same among selected records should be populated in the form

Part 1 addressed the first part of our user story. Now that we have our user's selection, we need to create an interface to allow them to select attributes affected by the bulk edit. Let's start with the form we'll use to POST our input.

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

# app/controllers/bulk_edits_controller.rb   def new   @foos = Foo.find(params[:stored_file_ids]) #params collected by work done in Part 1   @foo = Foo.new end     # app/views/bulk_edit/new.html.erb   <%= form_for @foo, :url => "/bulk_edits" do |f| %>   <% @foos.each do |foo| %>     <%= hidden_field_tag "foo_ids[]", foo.id %>   <% end %>   <%= render "foos/form", :f => f %>   <%= f.submit %> <% end %>

Let's first look at how we formed our form_for tag. Although this is a form for a Foo object, we don't want to POST to foos_controller#create so we add :url => "/bulk_edits" which will POST to the bulk_edits_controller#create. Additionally, we need to send along the foo_ids we eventually want to bulk update. Finally, we don't want to re-create the form we already have for Foo. By modifying one master form, we'll make long term maintenance easier. Now that we've got our form posting to the right place, let's see what modifications will need to make to our standard form to allow the user to highlight attributes they want to modify.

1 2 3 4 5

# app/views/foos/_form.html.erb   <%= check_box_tag "bulk_edit[]", :bar %> <%= f.label :bar %> <%= f.text_field :bar %>

Bulk edit check boxes appear in front of field names to let users know which fields will be modified.

We've added another check_box_tag to the form to record which attributes the user will select for bulk updating. However, we only want to display this when we're doing a bulk edit. Let's tweak this a bit further.

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

# app/views/foos/_form.html.erb   <%= bulk_edit_tag :bar %> <%= f.label :bar %> <%= f.text_field :bar %>   # app/helpers/foos_helper.rb   def bulk_edit_tag(attr)   check_box_tag("bulk_edit[]", attr) if bulk_edit? end   def bulk_edit?   params[:controller] == "bulk_edits" end

With these modifications to the form in place, the user can now specify which fields are eligible for bulk editing. Now we need the logic to determine how to populate the bar attribute based on the user's selection. This way, the user will see that an attribute is the same across all selected items. Let's revise our bulk edit controller.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

# app/controllers/bulk_edit_controller.rb   def new   @foos = Foo.find(params[:foo_ids])   matching_attributes = Foo.matching_attributes_from(@foos)   @foo = Foo.new(matching_attributes) end     # app/models/foo.rb   def self.matching_attributes_from(foos)     matching = {}   attriubtes_to_match = Foo.new.attribute_names  #see <a href="http://api.rubyonrails.org/classes/ActiveRecord/Base.html#method-c-attribute_names">attribute_names</a> for more details     foos.each do |foo|       attributes_to_match.each do |attribute|         value = foo.__send__(attribute)  #see <a href="http://apidock.com/ruby/Object/__send__">send</a>, invokes the method identified by symbol, use underscore version to avoid namespace issues         if matching[attribute].nil?         matching[attribute] = value  #assume it's a match         elsif matching[attribute] != value         matching[attribute] = "" #on the first mismatch, empty the value, but don't make it nil         end       end     end end

Only fields which are the same across all selected records will be populated. Other fields will be left blank by default.

With Foo#matching_attributes_for generating a hash of matching attributes, the form will only populate fields which match across all of the user's selected items. With our form in place, the last step is to actually perform the bulk edit.

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

# app/controllers/bulk_edits_controller.rb def create   if params.has_key? :bulk_edit       foos = Foo.find(params[:foo_ids])     foos.each do |foo|           eligible_params = {}         params[:bulk_edit].each do |eligible_attr|               #create hash of eligible_attributes and the user's value             eligible_params.merge! { eligible_attr => params[:foo][eligible_attr] }           end           #update each record, but only with eligible attributes         foo.update_attributes(eligible_params)       end   end end

We've now completed the entire user story. Users are able to use check boxes to identify which attributes should be bulk updated. They also get to see which attributes match across their selection. Things are, of course, always more involved with a real production application. Keep in mind this example does not make good use of mass assignment protection using attr_accessible and forcing an empty whitelist of attributes by using config.active_record.whitelist_attributes = true. This is a best practice that should be implemented anytime you need sever-side validation of your forms.

Additionally, there may be cases where you want to perform bulk edits of more complex attributes, such as nested attributes. Consider appending your additional attributes to the Foo.new.attribute_names array and then tweaking the eligible attributes logic. Also consider implementing a maximum number of records which are able to be bulk edited at a time; wouldn't want your server to time out. Good luck!

Performing Bulk Edits in Rails: Part 1

This will be the first article in a series, outlining how to implement a bulk edit in Rails 3.1.1 (although most any version of Rails will do). Today we'll be focusing on a simple user interface to allow the user to make a selection of records. But first, let's look at our user story.

The user story

• User makes a selection of records and clicks "Bulk Edit" button
• User works with the same form they would use for a regular edit, plus
• check boxes are added by each attribute to allow the user to indicate this variable should be affected by the bulk edit
• only attributes which are the same among selected records should be populated in the form

An example UI from Google's AdWords interface for
selecting multiple records for an action.

Sounds straight forward, right?  Well, there are a couple of gotcha's to be worked out along the way.

Capturing the user's selection

We'd like to offer the user a form with check boxes to click so when submitted, our controller gets an array of IDs we can pass to our ActiveRecord finder. It's best implemented using check_box_tag which means it's not auto-magically wired with an ActiveRecord object, which makes sense in this case because we don't want our form manipulating an active record object. We simply want to send our user's selection of records along to a new page.  Let's see what this looks like.

1 2 3 4 5 6 7 8

# app/views/search/_results.html   <% @foos.each do |foo| %>   <%= check_box_tag "foo_ids[]", foo.id  %> <% end %>   # when posted looks like # "foo_ids"=>["4", "3", "2"]

Because we now have an array of IDs selected, it becomes very easy for us to work with our user's selection.

1 2 3 4 5 6 7 8 9

# app/controller/bulk_edit_controller.rb   def new   if params[:foo_ids].is_a?(Array) && params[:foo_ids].length > 1  #let's make sure we got what we expected     @foos = Foo.find(params[:foo_ids])   else     redirect_to search_path   end end

Refining the UI with Javascript and CSS

It's not just enough to have these check boxes. We need our "Bulk Edit" button only to appear when the user has made an appropriate selection. Let's update our view code to give our tags some class.

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

# app/views/search/_results.html   <%= form_tag new_bulk_edit_path, :method => "GET", :id => "bulk-edit-form" do %>   <%= submit_tag "Bulk Edit", :id => "bulk-edit-submit" %> <% end %>   <div class="search_results">   <% @foos.each do |foo| %>     <%= check_box_tag "foo_ids[]", foo.id, false, :class => "downloadable"  %>   <% end %> </div>   # app/assets/stylesheets/search.css   #bulk-edit-submit {   input { display: none; } }

We've added the downloadable class tag to our check boxes, while adding a simple form to send data to the new_bulk_edit_path. This path corresponds to the new action, which typically, you don't post forms to (which is why we needed to be explicit about setting the GET method). However, in this case we need this information before we can proceed with a new bulk edit. We've also hidden the submit button by default. We'll need some Javascript to show and hide it.

1 2 3 4 5 6 7 8 9 10

# app/assets/javascripts/search.js   $('.downloadable').click(function() {     //when an element of class downloadable is clicked   var check_count = $('.downloadable:checked').size();  //count the number of checked elements   if( check_count > 1 ) {     $("#bulk-edit-submit").show();   } else {     $("#bulk-edit-submit").hide();   } });

At this point, you might have noticed that we're submitting a form with no fields in it! While we could simply wrap our form_tag around our search results, but we may not always want this. For example, what if we need multiple forms to be able to send our selection to different controllers in our application? Right now we're working on a bulk edit, but you know the client is expecting a bulk download as well. We can't wrap the same search results partial in multiple forms. Let's see how we would populate the our form using more Javascript.

1 2 3 4 5 6 7 8

# app/assets/javascripts/search.js   $('#bulk-edit').submit(function() {  //When the bulk-edit form is submitted   $('#bulk-edit input:checked').remove();  //clear all checked elements from form   var selected_items = $('.downloadable:checked').clone();   $('#bulk-edit').append(selected_items);   return true;  //VERY IMPORTANT, needed to actually submit the form });

This is a simple, unobtrusive way to give your forms a little more flexibility. It's also a good example of how to use :checked as a modifier on our jQuery selector.

Namespacing and Refactoring our Javascript

Knowing you'll need to implement a bulk-download form later in this same style, so let's refactor out this cloning functionality.

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

# app/assets/javascripts/search.js   $('#bulk-edit').submit(function() {   MyAppName.clone_downloadable_checkboxes_to($(this));  //You MUST wrap "this" inside $()   return true; });   if(!window.MyAppName) {   MyAppName = {};  //Initialize namespace for javascript functions }   MyAppName.clone_downloadable_checkboxes_to = function(destination) {   destination.children("input:checked").remove();   var selected_items = $('.downloadable:checked').clone();   destination.append(selected_items); };

One of the big highlights here is namespacing our Javascript function. While the chances are low that someone out there is going to have clone_downloadable_checkboxes_to in the global namespace too, it's always best to use proper namespaces.

Well, we've made it through the first part of our user story. The user can now check their boxes, and submit a form to the appropriate Rails resource. Stay tuned to see how we implement the second half of our user's story.