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
wentwj@gmail.com 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...@andreas-s.net>
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
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.
Oh, and yeah, you should use a _form.rhtml.erb as long as the forms are
the same ones. 