params v.s. @params in rails?

[Barry]

Both work in my controller class, so I am wondering what's the
difference and when should each one be used?

 

[David A. Black]

Hi --

Both work in my controller class, so I am wondering what's the
difference and when should each one be used?

To the extent that this is a Rails question, you might want to ask it
in a Rails forum (mailing list or IRC channel).

Meanwhile, the non-Rails-specific answer is that the bareword "params"
is a local variable, while "@params" is an instance variable. Local
variables are mainly a kind of "scratchpad" or temporary holding area
for data in the current local scope. Instance variables are unique
per object, rather than per scope, and give your objects a way to
maintain state across different methods and local scopes.


David

 

[Dema]

Not really. In this particular case, params is simply an accessor
method to the @params instance variable, not a local variable. So, in
practice, they´re equivalent.

The recommendation for using the params method, instead of accessing
the @params instance variable directly, is that it´s more uniform to
use the accessor method, since you can also do that from the view.

 

[David A. Black]

--8323328-357633517-1125848011=:1089
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-357633517-1125848011=:1089"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-357633517-1125848011=:1089
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

Not really. In this particular case, params is simply an accessor
method to the @params instance variable, not a local variable. So, in
practice, they=B4re equivalent.

Oh, *that* params

The recommendation for using the params method, instead of accessing
the @params instance variable directly, is that it=B4s more uniform to
use the accessor method, since you can also do that from the view.

You should be able to see your instance variables from the views too.


David

--=20
David A. Black
(e-mail address removed)
--8323328-357633517-1125848011=:1089--
--8323328-357633517-1125848011=:1089--

 

[Barry]

Thank you. That makes sense now. I found the following in
ActionController::Base of actionpack that explains what you are
describing,

attr_accessor arams

 

[David Heinemeier Hansson]

The recommendation for using the params method, instead of accessing

the @params instance variable directly, is that it=B4s more uniform to
use the accessor method, since you can also do that from the view.

Direct access to these instance variables is deprecated. The same goes
for cookies, session, request, response, and the other accessors. Use
the accessor instead of going directly, so it's request.get? instead
of @request.get?.
--=20
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

 

[Marcel Molina Jr.]

Direct access to these instance variables is deprecated. The same goes
for cookies, session, request, response, and the other accessors. Use
the accessor instead of going directly, so it's request.get? instead
of @request.get?.

Another reason is that the accessor method conceals the actual implementation
of params from the client which allows for a more flexible and cleaner
design.

marcel

 

[Douglas Livingstone]

=20
Direct access to these instance variables is deprecated. The same goes
for cookies, session, request, response, and the other accessors. Use
the accessor instead of going directly, so it's request.get? instead
of @request.get?.
=20

Is there a one-stop reference to the best practices for this sort of thing?

Douglas

 

[Devin Mullins]

David, Chet Hendrickson and I are just getting back to Ruby after too long away,
and we've just started working through the Rails book. Mostly happy so far,
though we're just a couple of days in.

One thing that confused me was the validate method in the first example. I'm
sure I'm missing something really obvious, but I'd rather be embarrassed than
confused. ;-> The validate is:

def validate
errors.addprice, "should be positive") unless price.nil? || price >= 0
end

I don't see how "price" canrefer to the field in the record, unless price
isperhaps an accessor kind of method. But in the class definition, I don't see
any declaration of a price method.

If it's not too much trouble, since we seem to be close to the topic ... what's
up with that? How does that access to price work?

Ron,

I'm nowhere near a Rails expert, and I'm definitely not David, but I do
own the book, and the example you're referring to (page 62) says that
this code goes in the model object. In the model object, yes, price is a
method invocation on self (a Product object) that returns the content of
the price column for that row. In Ruby, any undecorated symbolic
reference 'whatever' looks for a local variable first, and if not
defined? whatever, calls self.whatever.

If you're pulling up script/console and doing a Product.instance_methods
and not finding "price" listed, don't fret. It's most likely using
Product#method_missing (i.e. #doesNotUnderstand).

Hope that answers your question. Also, hope it's right.

Devin

 

[Ara.T.Howard]

David, Chet Hendrickson and I are just getting back to Ruby after too long away,
and we've just started working through the Rails book. Mostly happy so far,
though we're just a couple of days in.

One thing that confused me was the validate method in the first example. I'm
sure I'm missing something really obvious, but I'd rather be embarrassed than
confused. ;-> The validate is:

def validate
errors.addprice, "should be positive") unless price.nil? || price >= 0
end

I don't see how "price" canrefer to the field in the record, unless price
isperhaps an accessor kind of method. But in the class definition, I don't see
any declaration of a price method.

runtime and compile time aren't that different in ruby:

harp:~ > cat a.rb
class Row < ::Array
FIELDS = %w( product price )

def method_missing(m, *a, &b)
idx = FIELDS.index m.to_s
return self[idx] if idx
super
end
end

row = Row[ 'foobar', '17 bucks' ]

p row.price

harp:~ > ruby a.rb
"17 bucks"


this routes through method_missing each time, which is expensive, but you can
define the method at that point so future calls don't:

harp:~ > cat a.rb
class Row < ::Array
FIELDS = %w( product price )

def method_missing(m, *a, &b)
idx = FIELDS.index m.to_s
if idx
puts 'defining the method once...'
self::class.class_eval <<-definition
def #{ m }
self[ #{ idx } ]
end
definition
send m
else
super
end
end
end

row = Row[ 'foobar', '17 bucks' ]

2.times{ p row.price }


harp:~ > ruby a.rb
defining the method once...
"17 bucks"
"17 bucks"


it's precisely these sorts of possibilties which makes ruby such an attractive
means of writing code with dynamic responsibilies and requirements..

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================