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?
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
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
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?
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.