redirect_to doesn't stop rest of page processing ??

rubyonrails-talk
1

I've checked my books, google, API... I don't get it. A redirect_to doesn't really start a wholly new request. Code after a redirect_to still gets processed. The original request code isn't terminated.

A) what's the sense in that? B) how prevent it?

Example code causing me problem is below...

-- gw

application.rb

   before_filter :initialize_response

   def initialize_response      init_this      init_that      check_session_not_expired

     # processing continues here even if      # check_session_not_expired invokes the redirect_to

   end

   def check_session_not_expired      if (params[:controller] != 'login') &&         (!@current_user.login_is_valid? || !self.session_valid?)

        flash[:session_expired] = true         redirect_to(:controller => :login, :action => :login)    end

   def session_valid?      # do stuff      # return true or false    end

2

redirect_to is just a function. it would be a big magic if it could interrupt the flow of code if you want to you can always return after the redirect. In this particular case I'd put you check_session_nit_expired in a before_filter (redirecting does stop the filter chain). This is usually mentioned pretty explicitly in tutorials etc..

Fred

3

I've checked my books, google, API... I don't get it. A redirect_to doesn't really start a wholly new request. Code after a redirect_to still gets processed. The original request code isn't terminated.

A) what's the sense in that? B) how prevent it?

redirect_to is just a function. it would be a big magic if it could interrupt the flow of code

Hmmm. A simple Ruby abort command would do. In my previous Lasso life, a redirect including aborting the current request. In old versions we had to add the abort command manually after the redirect, but recent versions of the language finally added the abort internally, and made it a param option to not abort which was a much more logical way to go. Doesn't seem that magical to me.

if you want to you can always return after the redirect.

sure, but that doesn't stop the processing from continuing in the previous method which called the current one having the rediect -- which was the scenario I painted.

In this particular case I'd put you check_session_nit_expired in a before_filter (redirecting does stop the filter chain). This is usually mentioned pretty explicitly in tutorials etc..

I've juggled some things, but still not getting what I want. Looks like I have to reorganize quite a bit. I was counting on that redirect killing off the current request.

Seems I've just gotten "lucky" until now.

-- gw