The GitHub Repo

The Heroku App

This episode combines the technique shown in Episode 017 habtm checkboxes and Episode 35 Custom REST Actions to update a task’s complete attribute through checkboxes.]

Some of the differences in this episode were the methods used to update the complete attribute. In episode 035, the update_attribute() was used to update a single record. In this episode we used the update_all() method. There was a slight difference in how the update_all() method was used in the video and how it is currently used. In the video the update_all() method accepts two arguments, the attribute with updated value, plus the ids of tasks to be updated. The update_all() method has been changed to accept only one argument, the attribute with the updated value. This creates some problems in specifying which record to update. Luckily, the API for update_all showed the correct way to use the updated version of update_all().

Task.where(id: params[:task_ids]).update_all([“complete=?”, true])

We use the where() method to return tasks fitting the passed in conditional.

The params[:task_ids] were sent from the form within the view.

<%= form_tag complete_tasks_path, method: :put do  %>
  <ul>
    <% @incomplete_tasks.each do |task| %>
    <li>
      <%= check_box_tag "task_ids[]", task.id %>
      <%= task.name %>
    </li>
    <% end %>
  </ul>
  <%= submit_tag "Complete task" %>
<% end %>

Here we use the form_tag because the form is not directly editing attributes on a model. We then specify the path and method to put. I am just realizing this now, but this put should be a patch to match up with what the Rails core team has been doing in transitioning from put to patch to match with RFC’s specifications.

The next part to focus on is the <%= check_box_tag "task_ids[]", task.id %> line. We are creating checkboxes for each task with the value of the task’s id. The name for each checkbox can be specified to task_ids[] because we are using a general check_box_tag. task_ids[] allows the task_ids parameter sent from the form to be an array able to hold multiple records. This is where we get the params[:task_ids] array passed into the where() method.

The GitHub Repo
The Heroku App

This episode focused on creating a catch all route that redirects to a product’s page based on the partial route typed in. Example: /tele to /television

The routes syntax has been updated since the creation of the episode.

match '*path' => 'your_controller#your_action', via: :get

StackOverflow

You would want to create this catch all route at the bottom of your routes file because it would match all the requests coming into you Rails app otherwise. Because the match all routes redirects to the product page you actually are looking for, this isn’t that bad of an outcome.

After the route catches the input of the user from the route, it then calls the redirect#index. In this controller we can control the behavior of that route.

class RedirectController < ApplicationController
  def index
    if Rails.env.development? || Rails.env.test?
      product = Product.where('name LIKE ?', "#{params[:path].first}%").first
    elsif Rails.env.production?
      product = Product.where('name ILIKE ?', "#{params[:path].first}%").first
    end
    redirect_to product_path(product)
  end
end

In this controller I reused what I learned about PostgreSQL’s LIKE and ILIKE functions from the episode about Simple search forms to separate difference lines of code based on the environment.

There is a single action, index, that is called from the catch all route. We find where the product has a name that is similar to the partial parameter given in the route. We access this partial parameter through the params has with params[:path]. We also call first() to get the first value of the hash. If the user inputed /foo/bar/baz, then it would use the foo value only. Again from episode 037 simple search form, we use the SQL Wildcard % to match anything that starts with the partial route given. If there are multiple records that have the same partial route, then we call first() again at the end of the line to only retrieve the first record.

get '*path' => 'redirect#index'

class User < ActiveRecord::Base
  with_options if: :should_validate_password? do |user|
    user.validates_presence_of :password
    user.format_of :password, with: /^[^\s]+$/
  end

  attr_accessor :updating_password

  def should_validate_password?
    updating_password || new_record?
  end
end

class Account < ActiveRecord::Baase
  with_options dependent: :destroy do |acc|
    acc.has_many :customers
    acc.has_many :products
    acc.has_many :invoices
    acc.has_many :expenses
  end
end

This is a convenient method to be aware of. When there are numerous records that have the same options, then using with_options could clean up the code and it more DRY.

The with_options() method accepts the options as the first argument, then it accepts a block for the model class. This argument is the object used to call the validations on. In the case of user, user.validates_presence_of :password does the normal presence validation, but adds the benefit of using the with_options() method.

Further Reading

http://apidock.com/rails/Object/with_options

Gist

I ask myself when would I need to use a conditional validation. I could bypass certain validations based on a specific attribute being filled or not.

A big topic of late has been female founders not applying to accelerators/incubators like YC.

Continue reading →

GitHub Repo

Heroku App

I was originally going to create the episode 40 blocks in view, but there was a comment mentioning that episode 208 was the updated version. I did watch episode 40 nonetheless, and I noticed how much Rails has improved. The way to create a block in view in Rails 2 was by concatenating and using a block.binding. This seems like a hack compared today’s Rails standard.

For comparison the code for episode 40

def admin_area(&block)
  concat content_tag(:div, capture(&block), :class => 'admin'), block.binding if admin?
end

Episode 208

def admin_area(&block)
  content_tag(:div, :class => "admin", &block) if admin?
end

The line for the episode 208 was shorter because it eliminated concat capture() and block.binding. concat was rendered unnecessary after ERB used the <%= %> tag to signify whether or not the output would be rendered to the view. capture() tried to capture the output of a block’s yield. The content_tag now is able to accept a block as an argument without the need for capture(). block.binding binds to the erb templating. I’m not sure why this became unnecessary, but I suspect the revision of erb fixed this.

Assets Precompile

While pushing to Heroku the CSS I wrote for the admin_area was not being rendered. I eventually found the answer on StackOverflow. I did not have the rails_12factor gem. After further reading of the README for rails_12factor, rails_12factor allows static assets to be retrieved despite using a proxy like Nginx. A proxy like Nginx routes the asset path of assets/rails.png to public/assets/rails.png. Rails 4 is sort of encouraging the use of a CDN to host static assets. The Readme also linked to the ’12factor’ methodology which seems to touch on devops.

The GitHub Repo

The Heroku App

What I love about following the Railscasts and actually implementing the small features is that making these apps are quick, I’m exposed to something I wouldn’t have been otherwise, and they are straightforward. This episode was no different.

preview_button

<%= submit_tag 'Preview', name: 'preview_button' %>

The Preview button is similar to the the submit button, but it differs in it function. The name for the button defaults to commit when using the submit_tag helper. This is good when you need to create a normal submit button to create or update a record, but in the case of a preview button, you do not want to save the record just yet. Instead of having the name='commit we override this default by specifying the name should be equal to preview_button. With the name now equalling preview_button the parameters hash has "preview_button" => "Preview".

Controller

def create
...
  respond_to do |format|
    if params[:preview_button] || !@project.save
      format.html { render action: 'new' }
      format.json { render json: @project.errors, status: :unprocessable_entity }
    else
      format.html { redirect_to @project, notice: 'Project was successfully created.' }
      format.json { render action: 'show', status: :created, location: @project }
    end
  end
end

We can then use the params[:preview_button] within our conditional in the create action. If params[:preview_button] is not nil, then the controller will redirect to the new view while still having the preview_button parameter present in the URL. If there is no params[:preview_button] defined, then we know that the form was submitted through the normal submit button and not the preview button.

Textilize

<% if params[:preview_button] %>
  <div id="preview">
    <h2><%= @project.name %></h2>
    <%= textilize @project.description %>
  </div>
<% end %>

When we are redirected to the new view, the params[:preview_button] is still defined. We can use this in another conditional within our view to display a preview. Here we are previewing the project’s description using the textilize text helper. This was deprecated back in Rails 2, but I found a gem that dropped in to Rails 3+ that adds this back. There has to be a reason that the Rails Core Team deprecated this, so I do not plan to use this again. Instead I might reuse the code I used to render markdown to the view from my Markdown Todo List Rails API App

The GitHub Repo

The Heroku App

Form

<%= form_tag projects_path, method: :get do %>
<p>
  <%= text_field_tag :search, params[:search] %>
  <%= submit_tag 'Search', name: nil %>
</p>
<% end %>

The form for the search form has many lessons to learn. The use of form_tag over form_for is preferred we are not updating attributes associated with a specific model. Here the form_tag submits to the projects path. Normally when you submit a form using the form_for or form_tag Rails helper Rails create the html tags with a post method filled in. When you submit a post request to the projects path, Rails thinks you are trying to create a new record because of the RESTful design. To counteract this you have to explicitly specify the method used on this form, in this case get.

Controller

def index
  @projects = Project.search(params[:search])
end

Instead of the usual Project.all, we use a search method that we defined in the project model. The search method accepts a argument that is matched with records in the database.

Model

class Project < ActiveRecord::Base
  def self.search(search)
    if search
      if Rails.env.development?
        where("name LIKE ?", "%#{search}%")
      elsif Rails.env.production?
        where("name ILIKE ?", "%#{search}%")
      end
    else
      all
    end
  end
end

This is where most of the work is being done. Here we are defining a class method called search which accepts one parameter. If this parameter is true, then it will search for a name similar to the search argument. There is a conditional based on the environment because the LIKE function in SQLite3 used in development is case insensitive, while the LIKE function in PostgreSQL used in Production is case sensitive. PostgreSQL LIKE To counteract this, I have included the ILIKE function for only the production environment.

The "%#{search}%" confused me, so I asked on StackOverflow about what the % was. Apparently it is SQL Wildcards used to match characters in a string. It is similar to how Regex pattern matches, but SQL Wildcards are much simpler. It appears there are only four syntaxes that can be used. %, _, [], [^]. The % substitute zero or more characters. _ substitutes a single character. [] matches sets or ranges of characters. Example: [abc]% matches anything that starts with abc. Similar to regex you use ^ to declared not. [abc]% matches anything that does NOT start with abc. Similar to Regex, so this was not too mind blowing. The tricky part was learning the syntax used.