Filippos wrote in post #1014091:
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?
The begin-end block allows you to write multiple lines of code on the right side of an ||. It's the same as if you did this:
@current_user || method_1
def method 1 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
The return value of method1 gets inserted in place of the method1 'function' call on the right side of the ||.
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.
All classes have the same abilities in ruby. It doesn't matter whether you call a class a Model or a Controller or something else.
Not to mention the "self" outside a model class... very strange.
self refers to different objects depending on where you are in your code. The two main places that you need to know about is:
1) Inside a class but outside any def's, self refers to the class. 2) Inside a method definition, self refers to the object calling the method. And it appears that in most situations in rails, that is going to be the sess_controller = SessionsController.new object. Of course if you are inside a method in the UsersController, then rails will call those actions using a users_contr = UsersController.new object.
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-
Apparently, rails allows you to put some methods into a common directory when you want to use them in more than one controller. You put the methods inside a module, and save the file in the app/helpers directory. Then if you want to use the methods in a certain controller you write 'include ModuleName' in the application_controller.rb file:
class ApplicationController < ActionController::Base protect_from_forgery include SessionsHelper end
and that inserts the bundle of methods in the ApplicationController class. And because your controllers all inherit from the ApplicationController class:
class SessionsController < ApplicationController
...you can call any of the methods in the bundle from inside the actions in the SessionsController class.
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.
Yes.
So you mean that since we dont write "self" Rails infers:
self.method1 and self.method2(string1, string2, string3...) when we call them?
Yes. All methods must be called by some object. If you don't explicitly write the object in front of the method call, then ruby uses self.
with self being the session_controller = SessionsController.new or session_helper = SessionsHelper.new?
Inside an action, self will be the object calling the action, which will be the controller instance that rails creates to call the action. So for a SessionsController action, rails will create a sess_controller = SessionsController.new object, and for a UsersController rails will create a users_contr = UsersController.new object. The only way you can call methods in a class is if you first create an object of the class, and then use that object to call the methods. A controller is just a ruby class, and actions are just methods inside a class, so in order for an action to execute, it has to be called using an object of that class.
The reason the tests did not catch the typo in my code is because in the tests, is because the create actions calls the signed_in helper method, and signed_in does this:
@current_user = user
So when get_user_from_cookie is called:
def get_user_from_cookie @current_user || begin .... ....
@current_user is always true, so the right side of the || never executes. In other words, the tests we have written so far do not test the case when @current_user = nil. I don't know if that is an oversight, or whether that will be tested later.