[NotarySojac]

I'm going over this incredibly long rails tutorial, and there's a few blanks here and there. It looks like for authentication, in the users controller, they're using the below scheme:

(Regarding the destroy action)

class UsersController < ApplicationController
  before_filter :authenticate, :only => [:index, :edit, :update, :destroy]
  before_filter :correct_user, :only => [:edit, :update]
  before_filter :admin_user,   :only => :destroy
  .
  .
  .
  def destroy
    User.find(params[:id]).destroy
    flash[:success] = "User destroyed."
    redirect_to users_path
  end

  private
    .
    .
    .
    def admin_user
      redirect_to(root_path) unless current_user.admin?
    end
end

So am I to take it that,
...assuming that current_user.admin? == false,
......when it gets to the second before_filter,
.........it will execute the redirect_to(root_path), and
.........after it does that it will just stop trying to get to the destroy action since there's something magic about the "redirect_to" which causes the execution path to forget that it wanted to get to :destroy?

Is this a correct interpretation? (btw, the tut is at http://ruby.railstut..._before_filter)

[MitkOK]

There is no magic, it's simple redirect, everything after that line won't be evaluated.

[NotarySojac]

It looks like with the code

  def destroy
    if current_user?(User.find(params[:id]))      # if the current_user is the user being destroyed...
      flash[:error] = "Admins can't delete themselves."
      redirect_to users_path
      User.find(params[:id]).destroy  # destroy it anyway!  mwahahaha
      return false
    end
    User.find(params[:id]).destroy
    flash[:success] = "User destroyed."
    redirect_to users_path
  end

...it continues to execute after the redirect_to in the first if statement, up until the return statement.

[MitkOK]

Is the object destroyed then ? It seems that the if statements is false

[NotarySojac]

Nope, it seems like the redirect_to is kind of like a "soft return" which returns you from the chain of methods, but doesn't return you from the current method. I'm doing this in rails 3 which might behave differently if you're testing in rails 2.

[sepp2k]

Quote

after it does that it will just stop trying to get to the destroy action since there's something magic about the "redirect_to" which causes the execution path to forget that it wanted to get to :destroy?

Pretty much. Rails' view logic goes through the list of methods it needs to call (i.e. the before_filters and then the action) and if any of them sets a redirect, it stops calling the others and just executes the redirect.

Quote

it's simple redirect, everything after that line won't be evaluated.

That's not true. redirect_to definitely does not return from the current method. It's a simple method, not a control flow statement (nor does it throw any exceptions or perform some continuation magic which would alter control flow).

[MitkOK]

No, it's not a "soft return", it just a redirect. It's 100% sure that when you call it it will redirect to another action/page

@sepp2k
Where did I say that it's a control flow statement ? Everything after the redirect don't matter, you have brand new request.

Quote

Your code stops running and waits for a new request for the browser. It just happens that you’ve told the browser what request it should make next, by sending back an HTTP 302 status code.

This post has been edited by MitkOK: 08 July 2011 - 04:31 AM

[sepp2k]

MitkOK, on 08 July 2011 - 01:26 PM, said:

Where did I say that it's a control flow statement ?

You said that everything after it does not execute, which is simply false.

[MitkOK]

My bad. Everything after that evaluates and then it's never used.
And what is false is that I never said it's a control flow statement.

This post has been edited by MitkOK: 08 July 2011 - 07:47 AM

[sepp2k]

MitkOK, on 08 July 2011 - 04:47 PM, said:

My bad. Everything after that evaluates and then it's never used.

That depends. If you're setting instance variables, they are indeed never used. But if you for example execute a log statement, that ends up in the log file same as everything else. And if you execute another redirect, it will cause an error. So it's not accurate to say that what comes after does not matter.

Quote

And what is false is that I never said it's a control flow statement.

I didn't mean to say you did. To prevent subsequent statements from executing, redirect_to would need to throw an exception, perform some continuation magic, or be a control flow statement (or never return, but that wouldn't work either). I pointed out that it does neither of those things, to explain why the subsequents statements will execute.