I use Ajax more and more and I don’t see how a normal Scaffold for Rails
2+ is useful for that – with the ‘respond_to do |format|’. Or am I
missing something?
So how do I make a clean scaffold so I get:
def index
@documents = Document.find(:all)
end
def show
@document = Document.find(params[:id])
end
def new
@document = Document.new
end
def edit
@document = Document.find(params[:id])
end
def create
@document = Document.new(params[:document])
end
def update
@document = Document.find(params[:id])
end
def destroy
@document = Document.find(params[:id])
@document.destroy
end
To clean it up even more you could do:
before_filter :find_document, :except => [:index, :new, :create]
And then at the bottom before the end of the class:
private
def find_document
@document = Document.find(params[:id])
end
Bonus points for rescuing the ActiveRecord::RecordNotFound when somebody
passes in an ID that doesn’t exist.
Ryan B. wrote:
To clean it up even more you could do:
before_filter :find_document, :except => [:index, :new, :create]
And then at the bottom before the end of the class:
private
def find_document
@document = Document.find(params[:id])
end
Bonus points for rescuing the ActiveRecord::RecordNotFound when somebody
passes in an ID that doesn’t exist.
Great 
But what about a scaffold that doesn’t add all that extra? Is there a
way to do that?
Write your own?
On Jun 13, 2:15 am, Pål Bergström [email protected]
Bobnation wrote:
Write your own?
On Jun 13, 2:15�am, P�l Bergstr�m [email protected]
Not sure my knowledge in Rails is up to that yet, but I’m getting there
Maybe a good route would be to just generate the scaffold using script/
generate scaffold ScaffoldNameHere index show etc. which will give you
an outline to toy around with.
I guess the best advice I can probably hand out is go ahead and
destroy things!
On Jun 13, 7:36 am, Pål Bergström [email protected]
Bobnation wrote:
Maybe a good route would be to just generate the scaffold using script/
generate scaffold ScaffoldNameHere index show etc. which will give you
an outline to toy around with.
I guess the best advice I can probably hand out is go ahead and
destroy things!
On Jun 13, 7:36 am, Pål Bergström [email protected]
That’s a good idea. I’ll try it. Thanks.
you’re missing quite a bit of action here in your desire to DRY
everything
up, like saving the object in your create method and updating it in your
update one. you’d be much better served just learning and using the
Rails
defaults for a while before adapting and “cleaning” them up. you’ll
probably
even find out that they’re pretty fine the way they are.
RSL
On Fri, Jun 13, 2008 at 3:01 AM, Pål Bergström <
RSL ___ wrote:
you’re missing quite a bit of action here in your desire to DRY
everything
up, like saving the object in your create method and updating it in your
update one. you’d be much better served just learning and using the
Rails
defaults for a while before adapting and “cleaning” them up. you’ll
probably
even find out that they’re pretty fine the way they are.
RSL
On Fri, Jun 13, 2008 at 3:01 AM, Pål Bergström <
But from what I can understand it’s seldom that you will have any use of
the normal 2.0+ scaffold when doing things the AJAX-way, or?
There’s nothing wrong with writing yr own scaffolding. Not at all. But
from
your own code I surmise that you don’t really understand all the things
going on by default in Rails. That sounds rude but I’m honestly looking
out
for yr experience as a Rails dev. I too heard the siren call of “i can
make
this DRY” and “i can write this better than Rails” but i found that
until I
really groked the Rails way I often ended up making more work for
myself
trying to be clever. I really do suggest to all newcomers that they
resist
the urge to rethink and correct what they feel is wrong with Rails and
instead dine from the rich buffett DHH and crew have setup for us
already.
There’s nothing wrong with customization and adding on and even DRY
[though
i wish that term were stricken from tutorials and guides to new users
sometimes] but it’s always best to know how Rails does things first
before
second guessing it. Case in point:
def create
@document = Document.new(params[:document])
end
that method doesn’t actually save your document to the db. now look at
the
rails scaffolding for create and you can see that those lines you viewed
as
bloat and undry are all actually needed. there’s lines to initialize the
object and lines to save it and error handling as well. the scaffold is
anything but bloated. you’ll definitely be adding on to it later but you
should resist the urge to DRY up Rails default code.
RSL
On Tue, Jun 17, 2008 at 10:05 AM, Pål Bergström <
RSL ___ wrote:
There’s nothing wrong with writing yr own scaffolding. Not at all. But
from
your own code I surmise that you don’t really understand all the things
going on by default in Rails. That sounds rude but I’m honestly looking
out
for yr experience as a Rails dev.
That’s a good observation and completely true. That’s why I asked here.
Why use
respond_to do |format|
format.html # new.html.erb
format.xml
end
for situations where I use AJAX and have to add render :update do |page|
to each action anyway? This is what I’ve been trying to understand. I’m
just trying to learn the best way.
just remember the scaffolding isn’t meant as an end point but a
beginning.
you can just added format.js to the respond to block and delete the
format.xml line if you need. if you feel the need to make a new
scaffold,
you can easily base it off the rails scaffold simply changing a few
lines
here and there.
btw if you add the format.js then your ajax requests will look for
action_name.js.rjs where you can use your rjs. i prefer that personally
to
using inline rjs but either way will work.
RSL
On Tue, Jun 17, 2008 at 3:08 PM, Pål Bergström <