I didn’t see it outside a model class so im having problems
understanding and getting used to getter and setter outside a model
class since its the same thing.
A model class in rails is just a means for accessing a database. Rails
automatically creates accessor methods for all the attributes/columns in
your database. But you can always add setters and getters to a class,
which is all a Model is, with attr_accessor or writing them out by hand.
But when you add any extra setters and getters to a model, they won’t
correspond to any columns in the database. So
using the setter you added won’t save anything to the database, and
using the
getter won’t retrieve anything from the database.
The methods in a model class are not ‘actions’ because rails doesn’t map
urls to them. ‘Actions’ are the methods inside a controller class. And
rails maps urls to the actions, which is just a fancy way of saying that
when your rails app receives a request from a browser, rails executes
one of your actions. Which action rails executes when your app receives
a browser request is determined by the url of the request and which
action you tell rails to execute in response to that url in your
routes.rb file.
But both models and controllers are just ruby classes, so attr_accessor
can be used in both, and the rules about self are the same.
your implementation makes more sense to me than the example of the
book.
In your code you write:
def get_user_from_cookie
@current_user || begin <------- what is the begin ? or is that line
code a typo?
Pffff… it took me back to basics!
According to the book with attr_accessor we create virtual attributes
(when we dont want to save something in the database).
But it uses them inside a model class (user class) so it’s been called
as self.password (when attr_accessor :password)
I didn’t see it outside a model class so im having problems
understanding and getting used to getter and setter outside a model
class since its the same thing.
Not to mention the “self” outside a model class… very strange.
So the logic behind Helpers and the module is that when we’re not
using a model (px for Sessions) and since the code needed for sign-
in / sign-out doesn’t involve an action-view relationship like with
Controllers -it’s just methods and programming-
we use the SessionsHelper with modules and not the
ApplicationController.
About the methods.
def method1
…
end
is one type of method which doesn’t require an argument
whereas
def method2(string1, string2, string3…)
…
end
is the other type which requires input.
So you mean that since we dont write “self” Rails infers:
self.method1 and self.method2(string1, string2, string3…) when we
call them?
with self being the session_controller = SessionsController.new or
session_helper = SessionsHelper.new?
or is it any other object?
7stud – wrote in post #1014079:
Uggh. There must be a hole in my tests:
def get_user_from_cookie
@current_user || begin
cookie_array = cookies.signed[:remember_token]
if cookie_array
@current_user = User.authenticate_with_salt(*cookie_arr)
return @current_user
else
return nil
end
end # || block
end
*cookie_arr should be *cookie_array. But my tests didn’t throw an
error.
It turns my get_user_from_cookie method created a branch of code not
present in the book’s code. Namely, in the book when @current_user is
nil, then the right side of the || executes, and when that happens
User.authenticate_with_salt gets called no matter what the cookke_array
is equal to.
In my code, User.authenticate_with_salt doesn’t get called
if the cookie_array equals nil, and that creates a blind spot that the
tests don’t see.
To mimic the book’s code, I changed my method to this:
def get_user_from_cookie
@current_user || begin
cookie_array = cookies.signed[:remember_token] || [nil, nil]
@current_user = User.authenticate_with_salt(*cookie_arr)
end
end
Then the tests found the *cookie_arr error in my code, and changing that
to
*cookie_array got the tests to pass.