Rails - Apr 2005 - Forwarding control to another controller and action

In one of my actions, I''d like to check for a couple conditions, then
forward control to a particular action based on those conditions.  I
saw render_action, but that doesn''t seem to actually call the action
itself, but just render the view associated with that action.  The
actions I''d like to forward to may be in another controller. 
I''d like
this to be completely transparent, no URL change, so that any
parameters are maintained.  How can I do that?

On Apr 18, 2005, at 1:29 PM, Pat Maddox wrote:
> In one of my actions, I''d like to check for a couple conditions,
then
> forward control to a particular action based on those conditions.  I
> saw render_action, but that doesn''t seem to actually call the
action
> itself, but just render the view associated with that action.
This is only a half-answer to your question, but if the action *is* in 
the same controller, invoke that action as a method prior to to 
rendering its view. For example:

def index
	list
	render_action( :list )
end

On Tuesday, April 19, 2005, 10:45:37 AM, Gavin wrote:
> On Apr 18, 2005, at 1:29 PM, Pat Maddox wrote:
>> In one of my actions, I''d like to check for a couple
conditions, then
>> forward control to a particular action based on those conditions.  I
>> saw render_action, but that doesn''t seem to actually call the
action
>> itself, but just render the view associated with that action.
> This is only a half-answer to your question, but if the action *is* in
> the same controller, invoke that action as a method prior to to 
> rendering its view. For example:
> def index
>   list
>   render_action( :list )
> end
How if this different from the following?

  def index
    redirect_to :action => ''list''
  end

Why would you choose one over the other?

Gavin

On Apr 18, 2005, at 7:54 PM, Gavin Sinclair wrote:
>> def index
>>   list
>>   render_action( :list )
>> end
>
> How if this different from the following?
>
>   def index
>     redirect_to :action => ''list''
>   end
>
> Why would you choose one over the other?
I''m just a rails noob, but I believe that redirect_to sends an HTTP 
redirect response (HTTP 302, I think) like ASP''s Response.Redirect, 
which causes the web browser to go fetch the new URL.

What I wrote (or rather, stole from a wiki page somewhere) send the 
contents of the view as the response, without causing the browser to 
change url (and with 1 less client/server roundtrip).


--
(-, /\ \/ / /\/

> > def index
> >   list
> >   render_action( :list )
> > end
> 
> How if this different from the following?
> 
>   def index
>     redirect_to :action => ''list''
>   end
> 
> Why would you choose one over the other?
The former is handled by the server, and is transparent to the end
user. The latter causes the web browser to terminate the request and
establish a new one. The latter is, in terms of network bandwidth used
for HTTP headers and CPU cycles required to initialise Rails for a new
request, very expensive. The former is almost free.

-- 
Phillip Hutchings
http://www.sitharus.com/
sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org /
sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org

On 4/19/05, Phillip Hutchings
<sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > > def index
> > >   list
> > >   render_action( :list )
> > > end
> >
> > How if this different from the following?
> >
> >   def index
> >     redirect_to :action => ''list''
> >   end
> >
> > Why would you choose one over the other?
> 
> The former is handled by the server, and is transparent to the end
> user. The latter causes the web browser to terminate the request and
> establish a new one.  The latter is, in terms of network bandwidth used
> for HTTP headers and CPU cycles required to initialise Rails for a new
> request, very expensive. The former is almost free.
I''d say that performance is almost irrelevant.  Your average GET
request is what,  500bytes of data.   You probably send down more
javascript than that.   the additional CPU cycles are probably
miniscule too.   Performance is not a justification here,  unless you
can show profiling results showing otherwise.

Basically,  I''d favour the redirect as it''ll let your users
reload the
page,  and let proxies cache the result.   If you *need* to use some
fancy dispatching then look into it, otherwise just stick with the
simplest thing that could possibly work.

> 
> --
> Phillip Hutchings
> http://www.sitharus.com/
> sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org /
sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Cheers

Koz

> I''d say that performance is almost irrelevant.  Your average GET
> request is what,  500bytes of data.   You probably send down more
> javascript than that.   the additional CPU cycles are probably
> miniscule too.   Performance is not a justification here,  unless you
> can show profiling results showing otherwise.
> 
> Basically,  I''d favour the redirect as it''ll let your
users reload the
> page,  and let proxies cache the result.   If you *need* to use some
> fancy dispatching then look into it, otherwise just stick with the
> simplest thing that could possibly work.
You forget that TCP requires the three way handshake. Say I am 200ms
away from my server, a pretty common figure where I am. Three packets,
600ms, then request data, 200ms,  then processing, then data, ack,
data, ack,..., fin. Most browsers start rendering with the first data
packet, so we can disgard that. So, 600ms to set up a TCP connection,
200ms to send the request, 300ms to process a page, another 200ms to
get the initial packet back. That''s 1.3 seconds lag. It may sound
small, but if you''ve just submitted a form there''s already the
last
second there, so it''s 3 seconds from click until you see the next page
rendering. Dialup has a higher latency, as do some DSL providers.

Of course, if the connection is using keep_alive then it''ll be much
quicker, but there''s still the response<->request cycle which can
be
avoided.

On the other hand, internal redirects, really a method call, takes
next to no time. 800ms to submit a request, then two 300ms method
calls and a reply takes just over one seconds. That''s nearly a third
of the time.

Choose. redirect_to is simpler, but latency can be really high.

-- 
Phillip Hutchings
http://www.sitharus.com/
sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org /
sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org

Pat,

You can either use the render_component functionality (see the api docs 
on components) or use my "delegate" functionality (see some older 
e-mails from this list, and if you can''t find it, let me know,
i''ll send
the cod to you)

Kind regards,
Flurin

Pat Maddox wrote:
>In one of my actions, I''d like to check for a couple conditions,
then
>forward control to a particular action based on those conditions.  I
>saw render_action, but that doesn''t seem to actually call the
action
>itself, but just render the view associated with that action.  The
>actions I''d like to forward to may be in another controller. 
I''d like
>this to be completely transparent, no URL change, so that any
>parameters are maintained.  How can I do that?
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>  
>

redirect_to triggers a round-trip to the browser and back again to the 
"list" action. Whereas list;render_action(:list) doesn''t, it
just calls
the list method in the controller and then renders its view.

Gavin Sinclair wrote:
>On Tuesday, April 19, 2005, 10:45:37 AM, Gavin wrote:
>
>  
>
>>On Apr 18, 2005, at 1:29 PM, Pat Maddox wrote:
>>    
>>
>>>In one of my actions, I''d like to check for a couple
conditions, then
>>>forward control to a particular action based on those conditions.  I
>>>saw render_action, but that doesn''t seem to actually call
the action
>>>itself, but just render the view associated with that action.
>>>      
>>>
>
>  
>
>>This is only a half-answer to your question, but if the action *is* in
>>the same controller, invoke that action as a method prior to to 
>>rendering its view. For example:
>>    
>>
>
>  
>
>>def index
>>  list
>>  render_action( :list )
>>end
>>    
>>
>
>How if this different from the following?
>
>  def index
>    redirect_to :action => ''list''
>  end
>
>Why would you choose one over the other?
>
>Gavin
>
>
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>  
>