Rails - Nov 2007 - Scaffold: What's the advantage of actions create/update?

Hi all

I''m quite unsure what''s the point to have a create and update
action in
the Rails scaffolds... I guess the developers had good reason to
implement them, but I don''t really see the reason for them...

Why no just checking for get/post within the same new/edit method?

def new
  unless request.post?
    # do the normal "new" stuff
  else
    # do the stuff from the "create" method
  end
end

def edit
  unless request.post?
    # do the normal "edit" stuff
  else
    # do the stuff from the "update" method
  end
end

Anybody can tell me what''s the big advantage of splitting the above
methods into new/create and edit/update methods?

Thanks a lot,
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
-~----------~----~----~----~------~----~------~--~---

Because the code is much more readable when it''s separated out into
different methods and allow routing to direct the request to the
appropriate method based on post/get.

The way you described above would work but the way the scaffold
generator is creating is it to have each method be as simple as
possible.  I don''t see an advantage to putting them into one method,
any code you want them to share can be re-factored out into a before
filter which runs before each method

On Nov 21, 6:33 am, Joshua Muheim
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Hi all
>
> I''m quite unsure what''s the point to have a create and
update action in
> the Rails scaffolds... I guess the developers had good reason to
> implement them, but I don''t really see the reason for them...
>
> Why no just checking for get/post within the same new/edit method?
>
> def new
>   unless request.post?
>     # do the normal "new" stuff
>   else
>     # do the stuff from the "create" method
>   end
> end
>
> def edit
>   unless request.post?
>     # do the normal "edit" stuff
>   else
>     # do the stuff from the "update" method
>   end
> end
>
> Anybody can tell me what''s the big advantage of splitting the
above
> methods into new/create and edit/update methods?
>
> Thanks a lot,
> Josh
> --
> Posted viahttp://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
-~----------~----~----~----~------~----~------~--~---

wentwj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Because the code is much more readable when it''s separated out
into
> different methods and allow routing to direct the request to the
> appropriate method based on post/get.
> 
> The way you described above would work but the way the scaffold
> generator is creating is it to have each method be as simple as
> possible.  I don''t see an advantage to putting them into one
method,
> any code you want them to share can be re-factored out into a before
> filter which runs before each method
> 
> On Nov 21, 6:33 am, Joshua Muheim
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
But how to "DRY" with the views? Both views (edit.html.erb and 
new.html.erb) seem to contain similar code.
Shall I use something like a _form.html.erb ?
Or shall I render only one view in the controller?

TIA,
Martin
-- 
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
-~----------~----~----~----~------~----~------~--~---

> But how to "DRY" with the views? Both views (edit.html.erb and 
> new.html.erb) seem to contain similar code.
> Shall I use something like a _form.html.erb ?
> Or shall I render only one view in the controller?
> 
> TIA,
> Martin
They seem as long as it''s only basic functionality. But the more
complex
a project becomes, the more the new and edit views will differ, so
don''t
"over-DRY" a project before it represents all your needs. Elsewise you
may come to a point where you "un-DRY" code you have wasted hours to 
"DRY" before.
-- 
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
-~----------~----~----~----~------~----~------~--~---

Oh, and yeah, you should use a _form.rhtml.erb as long as the forms are 
the same ones. :-)
-- 
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
-~----------~----~----~----~------~----~------~--~---