The part that really confused me on p. 345 is where the
author says:
==
self.current_user = user
The purpose of this line is to create current_user, accessible in both
controllers and views which will allow constructions such as:
<%= current_user.name %>
and
redirect_to current_user
==
The author says "current_user" not 'the current_user function". He
refers to current_user as if it's a variable. In addition, up to that
point
in the book we have been using @ variables in the view. So it seems
clear
to me that the real purpose of that line is to set the instance variable
@current_user, whose value can be retrieved with the 'function'
current_user, or whose value can be set with the 'function'
current_user=. I am quoting the word 'function' because in ruby, defs
are called methods--not functions.
It follows that the line:
<%= current_user.name %>
actually does this:
<%= current_user().name %>
However, the current_user function can be rewritten like this:
def current_user
#If for some reason @current_user already
#exists, return its value:
return @current_user if @current_user
#Check if the browser request contains a
#cookie named remember_token:
cookie_arr = cookies.signed[:remember_token]
if cookie_arr.nil?
return nil
else
return User.authenticate_with_salt(*cookie_arr)
end
end
But that function can return nil, so writing the following in the view:
<%= current_user.name %>
or writing this in an action:
redirect_to current_user
will cause errors if current_user is nil.
What I found to be a new concept in this section of the book is that we
can
call methods in the view that are inherited by the
controller:
SessionsHelper
...
...
def current_user
...
end
end
class ApplicationController < ActionController::Base
...
include SessionsHelper
end
class SessionsController < ApplicationController
def new
end
def create
end
def destroy
end
end
Interestingly, if you put the method directly in the controller, e.g.
class SessionsController < ApplicationController
def new
end
def create
end
def destroy
end
def current_user
...
...
end
end
...then rails will throw an error.
*****
Something else I found very confusing was this on p. 348:
==
def current_user=(user)
@current_user = user
end
def current_user
@current_user
end
...
...
The problem is that it utterly fails to solve our problem: with the code
[above] the user's sign in status would be forgotten: as soon as the
user went to another page--poof!--the session would end and the user
would be automatically signed out.
==
Huh? It's my understanding that the created sess_controller object
which rails uses to call the methods defined in the SessionsController
class, including the inherited methods like current_user, is going to go
poof! anyway, along with all its instance variables like @current_user.
No code we write can prevent that.
The trick is to store the signed in status of the user in a cookie on
the browser before the sess_controller object goes poof!, and then every
time the browser makes another request for a page, we check to see if
the cookie named 'remember_token' gets added to the request (a browser
adds all cookies from our app to the request before sending the
request). If the cookie is present and contains the right information,
then we know the user is signed in; and if the cookie isn't present,
then the user isn't signed in.
So what I think the author is trying to say about this function:
def current_user
@current_user
end
is that the function will always return nil when the browser goes to
another page, so need to define it so that it checks for a cookie in the
browser request.
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
