Documentation for scaffold / views


#1

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?

THanks


#2

On 1/18/06, dr plutes removed_email_address@domain.invalid wrote:

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:

RAILS_ROOT/vendor/rails/actionpack/lib/action_controller/scaffolding.rb


#3

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


#4

Kevin O. wrote:

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?