e168f08 - Latest Comments in Slightly updated version of the “crud” app on downloads page

Re: Slightly updated version of the “crud” app on downloads page

mobile application development — Fri, 13 Nov 2009 18:03:54 -0000

Wow thanks for this really useful update. I was using the old version, but I will download the new one of course. Oh my I have spotted that this pose is written over a year ago only now. What an interesting thing - it is actually written a year ago, on 14 november 2008 :)) Nice one. However I will definitely download this application and try it out. Thanks one more time for your efforts.

Re: Slightly updated version of the “crud” app on downloads page

ouadamantite — Mon, 02 Nov 2009 09:26:00 -0000

-> @student = Student.new(params[:student]) how are you getting parameters though ?
__________________________________________
My erectie site.

Re: Slightly updated version of the “crud” app on downloads page

picture cataloging software — Sat, 10 Oct 2009 10:50:41 -0000

thanks for the heads up, this really helped me a lot..

Re: Slightly updated version of the “crud” app on downloads page

DoctorPsi — Thu, 27 Aug 2009 14:07:39 -0000

It seems that your coding is very logical and coherent, but it doesn't work as it should... Why is that?
_______________________________
Online Degrees

Re: Slightly updated version of the “crud” app on downloads page

jgn — Fri, 14 Nov 2008 10:01:18 -0000

Hey, one more thing following up my earlier reply:

This is probably a good case for a private method which both new and create would leverage -- that private method would load up @sections for the drop-down.

Re: Slightly updated version of the “crud” app on downloads page

jgn — Fri, 14 Nov 2008 07:31:38 -0000

You can do it either way -- there is no really standard way to do this.

Both solutions are problematic.

If you create a new set of @sections in create, then you're not DRY. If you do "@student ||= Student.new" and call the "new' method, then your "new" method isn't really create a NEW @student in all cases, so if you think that the method name should be explanatory, then you've given up on that. Which is fine if that's what you want. I have done it both ways myself.

In a more complicated strategy, you would "dry" up the entire new/create/edit/update cycle -- but that would require more trickery than we need right now. For pedagogical purposes -- and in this particular case -- I think the direct approach explains pretty clearly how when you get to that form, all of the data it needs must be in place.

Re: Slightly updated version of the “crud” app on downloads page

Morris — Fri, 14 Nov 2008 00:05:49 -0000

I'm unhappy about this fix, because you're repeating yourself, and now two different methods have information about what the "new" view expects for instance variables, making the code a little fragile. I would suggest, instead of the new "#important line!", a call to the new METHOD, to pick up the necessary data, making the create method look like

def create
@student = Student.new(params[:student])
if @student.save
redirect_to :action => :index
flash[:notice] = 'Student was successfully created.'
else
new #set up instance variables expected by the new view
render :action => :new
end
end

and, understanding that the reason we're doing this render instead of just redirecting to new is to preserve the value of @student, we could rewrite the second line of the new method as

@student ||= Student.new

to prevent overwriting the value, if it's there.