Archive for October, 2008

Cancel Forms And Avoid The If Then Statements

Thursday, October 16th, 2008

One of the big pains with Rails form helpers is that they don't have a cancel button. No, problem - that is easy enough to add in. Just use a second submit tag like so:

            <%= f.submit "Create" %>
            <%= submit_tag "Cancel" %>

Now, if the user clicks the "Cancel" button a "commit" param with a value of "Cancel" will be submitted.

This is nothing earth-shattering. I have found this technique on various blogs. But then they all suggest checking for this parameter in the update or create method of your controller. I don't like this because it makes you add in extra "if-then" statements. I really hate "if-then" statements. They make the code so much harder to read.

So what to do?

Use a before filter.

before_filter :check_for_cancel, :only => [:create, :update]

Then add in your method to check for the cancel parameter in the commit message.

  private
  
  def check_for_cancel
    if params[:commit] == "Cancel"
      redirect_to admin_spaces_path
    end
  end

That's it. So now, if anyone clicks on the "Cancel" button on an edit or new form they will be redirected to the index.

If you really wanted to you could make the Cancel button submit the cancel parameter as part of the model hash. You would do it like this:

            <%= submit_tag "Cancel", :name => "model[cancel]" %>

You would just need to update your check_for_cancel method to check for that param. I prefer the previous method though since it is more generic.

ScreenSteps Live: A Case Study on Ruby on Rails - Part 2 - Figuring Out the Code

Tuesday, October 14th, 2008

In my last post about developing ScreenSteps Live with Ruby on Rails (which was far too long ago) I talked a lot about what led to me getting started with Rails development. In this post I want to talk about what were some of the things about Ruby and Rails that I found really useful and what things were really confusing.

Once again - a little of my background. When I started this I had a music degree from the Berklee College of Music, knew some basic HTML and was at least competent at using CSS thanks to the book "CSS: The Missing Manual", which I can't recommend enough.

So I was by no means a programming expert. Concepts such Classes, Modules, ActiveRecord, View Helpers, Partials, Arrays, and Hashes were all totally foreign to me. I had done some database work several years ago where I got to dig into SQL commands a bit. This background at least gave me a good understanding of how relational databases worked.

The Stuff That Confused Me

Here are some of the things that initially confused me about Ruby and Rails:

Block notation

It looks something like this:

@posts.each {|p| p.some_method}

For some reason that totally confused me. Once you figure it out it is wonderful and very powerful. But as I read books and searched the internet I could find all these things that mentioned blocks but didn't define what they were or how they worked. I think that I will do a post soon about the important things I wish I had known about blocks but I don't have space for that here. Now that I understand them I can find plenty of information on them. Isn't that always the case?

Ternary operators

url.blank? ? "Preview not available" : url

That type of stuff totally threw me for a loop. All it is doing is evaluating an expression and returning a value depending on the value returned by the expression. It is short hand for an if-then statement. But those ? and : are very intimidating when your code vocabulary is limited.

Array Operators

posts.collect {|p| p.title } posts.select {|p| p.title == "My Post"}

I didn't like that stuff at all, mainly because I wasn't comfortable with arrays yet. That compounded with the block notation had me dong a lot of head scratching.

The Stuff I Liked

(more…)