Rails - Oct 2007 - Do I have to care about other methods than GET and POST?

Hi all

Sometimes I check in a controller if the method is GET or POST. But
afaik there are other methods - do I have to care about them?

Is the following enough?

if request.get?
...
elsif request.post?
...
end

Or do I have to add also an else block?

if request.get?
...
elsif request.post?
...
else
  raise "Boah!"
end

Thanks for infos
Josh
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> Sometimes I check in a controller if the method is GET or POST. But
> afaik there are other methods - do I have to care about them?
>
> Is the following enough?
>
> if request.get?
> ...
> elsif request.post?
> ...
> end
>
> Or do I have to add also an else block?
>
> if request.get?
> ...
> elsif request.post?
> ...
> else
>   raise "Boah!"
> end

IMO, defensive programming says there should almost always be an else  
in these type of constructs unless they''re being used to prepare  
special cases for the code that follows (code which doesn''t care if  
there''s neither a GET nor POST).

So, what will your program do if neither of the first two are  
satisfied? If the code must have one or the other, then yes, you need  
an else. If the code modifies something in the cases of GET/POST and  
otherwise runs just fine if there is no GET/POST, then you do not  
need the else (because it would halt processing you''re expecting to  
happen).

-- gw


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Just to add to the last reply, there are now other very commonly used
methods. Namely PUT, DELETE and sometimes HEAD. Rails 1.2 started this
and Rails 2.0 will go beyond even what''s being done in 1.2. Not adding
more methods, but "scaffold_resource" is now simply
"scaffold." When
generating scaffolding you will get RESTful controllers by default
using the full set of HTTP methods.

However, keep in mind that if the request is being generated from a
web form it will use GET or POST (at least until browsers get smart
enough to handle the other methods). That being said in a modern Rails
application you can''t count of the request coming from a HTML form. It
just might be coming from another client that does understand the full
REST method set, or even from a command line on the terminal.

On Oct 24, 5:24 pm, Greg Willits
<li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org>
wrote:
> > Sometimes I check in a controller if the method is GET or POST. But
> > afaik there are other methods - do I have to care about them?
>
> > Is the following enough?
>
> > if request.get?
> > ...
> > elsif request.post?
> > ...
> > end
>
> > Or do I have to add also an else block?
>
> > if request.get?
> > ...
> > elsif request.post?
> > ...
> > else
> >   raise "Boah!"
> > end
>
> IMO, defensive programming says there should almost always be an else  
> in these type of constructs unless they''re being used to prepare  
> special cases for the code that follows (code which doesn''t care
if
> there''s neither a GET nor POST).
>
> So, what will your program do if neither of the first two are  
> satisfied? If the code must have one or the other, then yes, you need  
> an else. If the code modifies something in the cases of GET/POST and  
> otherwise runs just fine if there is no GET/POST, then you do not  
> need the else (because it would halt processing you''re expecting
to
> happen).
>
> -- gw

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

If you really need to check for specific http verbs, the else is a
must. Browsers are not smart enough to send anything than
GET/POST, but other HTTP clients are, e.g.: wget, curl, just to
name a few. curl can also send invalid http verbs.

Rails provide a much better way of doing http verb checks, the
verify method [1]. It also allow you to check for http/session
parameters and xhr.

If verify method not suit your needs, i will try to use a more
idiomatic
code like this.

request_is(request) do |verb|
  verb.post { do_something1 }
  verb.get   { do_something2 }
  verb.head { do_somethind3 }
  ...
end

The main idea is to encapsulate common behaviour for all actions
in a request proxy. I mean, logging, mail to administrators, or
whathever else you need to do, and pass the other method calls
to the real request instance through Object#send

references:
[1]
http://api.rubyonrails.com/classes/ActionController/Verification/ClassMethods.html


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

If you really need to check for specific http verbs, the else is a
must. Browsers are not smart enough to send anything than
GET/POST, but other HTTP clients are, e.g.: wget, curl, just to
name a few. curl can also send invalid http verbs.

Rails provide a much better way of doing http verb checks, the
verify method [1]. It also allow you to check for http/session
parameters and xhr.

If verify method not suit your needs, i will try to use a more
idiomatic
code like this.

request_is(request) do |verb|
  verb.post { do_something1 }
  verb.get   { do_something2 }
  verb.head { do_somethind3 }
  ...
end

The main idea is to encapsulate common behaviour for all actions
in a request proxy. I mean, logging, mail to administrators, or
whathever else you need to do, and pass the other method calls
to the real request instance through Object#send

references:
[1]
http://api.rubyonrails.com/classes/ActionController/Verification/ClassMethods.html


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thank you, guys.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---