Both work in my controller class, so I am wondering what's the
difference and when should each one be used?
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
···
On Sun, 4 Sep 2005, Barry wrote:
--
David A. Black
dblack@wobblini.net
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 wrote:
···
Hi --
On Sun, 4 Sep 2005, Barry wrote:
> 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
--
David A. Black
dblack@wobblini.net
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´re equivalent.
Oh, *that* params 
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.
You should be able to see your instance variables from the views too.
David
···
On Mon, 5 Sep 2005, Dema wrote:
--
David A. Black
dblack@wobblini.net
Thank you. That makes sense now. I found the following in
ActionController::Base of actionpack that explains what you are
describing,
attr_accessor :params
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.
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?.
···
--
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
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
···
On Mon, Sep 05, 2005 at 01:26:44AM +0900, David Heinemeier Hansson wrote:
> 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.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?.
--
Marcel Molina Jr. <marcel@vernix.org>
Is there a one-stop reference to the best practices for this sort of thing?
Douglas
···
2005/9/4, David Heinemeier Hansson <david.heinemeier@gmail.com>:
> 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.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?.
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.add(:price, "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?
Thanks,
···
On Mon, 5 Sep 2005 01:26:44 +0900, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:
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.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?.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ron Jeffries wrote:
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.add(:price, "should be positive") unless price.nil? || price >= 0
endI 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
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"
it's precisely these sorts of possibilties which makes ruby such an attractive
means of writing code with dynamic responsibilies and requirements..
cheers.
-a
···
On Thu, 15 Sep 2005, Ron Jeffries wrote:
On Mon, 5 Sep 2005 01:26:44 +0900, David Heinemeier Hansson > <david.heinemeier@gmail.com> wrote:
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.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?.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.add(:price, "should be positive") unless price.nil? || price >= 0
endI 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.
--
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
===============================================================================