Apparently a scaffold creates at least one instance variable for views
to use, and if I override the scaffold then I must also explicitly
create that instance variable for the view. I’d like to know exactly
what work is performed by the scaffold so that I can know this when
over-riding the view. (OR, is it that the controller makes these
variables available by default?..)
EXAMPLE: (drawn from Recipes tutorial)
Let’s start with this:
class CategoryController < ApplicationController
scaffold :category
end
Now app/views/category/show.rhtml can access @category. However as soon
as I over-ride the show, like so…
class CategoryController < ApplicationController
scaffold :category
def show
end
end
…@category is no longer available to the show view because I neglected
to do so explicitly. I can fix that like so:
class CategoryController < ApplicationController
scaffold :category
def show
@category = Category.find(params[:id])
end
end
Which docs or code would tell me more about this and other such
variables and methods that are made available by either the controller
or scaffold and that I must take care to recreate if I over-ride the
category controller?
Which docs or code would tell me more about this and other such
variables and methods that are made available by either the controller
or scaffold and that I must take care to recreate if I over-ride the
category controller?
Assuming you are running Edge Rails, the code is in:
It would also be a good idea to simply run the scaffold generator. That
will actually spell out all the code for you in a controller file. You
can then replace stuff as needed, but you can also see the code.
It would also be a good idea to simply run the scaffold generator. That
will actually spell out all the code for you in a controller file. You
can then replace stuff as needed, but you can also see the code.
ruby script/generate scaffold model
_Kevin
YeaH, I’ve started to do that with my new rails apps. I have an earlier
one that I still use and didn’t want to wipe out my work done by
generating the scaffold. I’m not quite sure how well the --skip option
avoids overwrites either, but yeah henceforth that’s the way I’m going
to go every time. Is there any reason NOT to just generate the full
scaffold every time?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.